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Abstract 

Improvements  in  technology,  especially  in  computer  science,  in  last  two  decades 
have  made  it  possible,  and  preferable  to  develop  digital  technical  manuals.  A  digital 
manual,  which  is  called  an  Interactive  Electronic  Technical  Manual  (IETM),  is  a  package 
of  information  required  for  the  diagnosis  and  maintenance  of  a  weapon  systems, 
optimally  arranged  and  formatted  for  interactive  screen  presentation  to  the  end-user. 
Being  the  largest  organization  in  the  U.S.,  the  Department  of  Defense  has  pioneered  in 
the  development  of  IETM  concept  as  well  as  in  the  establishment  of  its  standards.  There 
have  been  many  researches  done  about  different  IETM  applications  and  their 
effectiveness  in  DoD  environment.  However,  little  research  has  been  done  in  the  area  of 
how  an  IETM  is  developed  in  a  civilian  environment.  This  thesis  identifies  what  it  takes 
to  develop  an  IETM  in  a  civilian  environment  and  investigates  differentiating  factors  of 
commercial  industry.  In  addition  to  the  identification  of  IETM  development  steps  in  a 
case  study,  IETM  standards,  IETM  development  specifications  in  industry  as  well  as  in 
military,  problems  areas  in  today’s  IETM  development  environment,  and  DoD 
classification  of  IETMs  are  also  discussed. 
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HOW  TO  DEVELOP  AN  INTERACTIVE  ELECTRONIC  TECHNICAL  MANUAL: 

AN  INDUSTRY  PERSPECTIVE 


I.  Introduction 


Overview 

Advances  in  computer  technology  in  the  last  two  decades  have  given  to  the 

advent  of  Interactive  Electronic  Technical  Manual  (IETM).  IETMs  are  designed  to 

provide  interactive  display  of  required  task  procedures,  and  associated  graphics  to 

maintenance  technicians  or  system/equipment  operators.  There  are  many  applications  in 

Department  of  Defense  (DoD)  as  well  as  industry.  DoD  requires  all  new  contracts 

require  on-line  access  to,  or  delivery  of,  their  programmatic  and  technical  data  in  digital 

form  (DoD  5000.2-R,  1998).  So,  what  are  the  benefits  of  IETMs  to  technicians  or  system 

operator  in  the  field,  and  to  organization  themselves?  Mr.  Tisdale,  an  action  officer  for 

the  New  System  Training  Division,  Department  of  Training  Plans  and  Evaluation,  at  the 

United  States  Army  Aviation  Logistics  School,  Fort  Eustis,  Virginia,  expressed  his 

thoughts  about  IETMs  (Tisdale,  1998): 

Have  you  ever  chased  an  electrical  problem  on  an  aircraft?  Usually  on  the 
third  or  fourth  day  since  the  fault  was  discovered,  and  at  ‘0’  dark  in  the 
middle  of  the  night,  and  the  aircraft  “must”  be  ready  to  fly  the  most 
important  mission  of  all  times  in  just  eight  more  hours,  you  think  you  have 
the  problem  pretty  well  figured  out.  After  all,  you  have  been  through  no 
less  than  five  technical  manuals  and  at  least  double  that  many  wiring 
diagrams.  No  one  can  remember  all  the  schematics  and  then  find  out  that 
the  manual  that  you  are  using  is  now  referring  you  to  yet  another  technical 
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manual  to  ‘aid’  in  this  fault  isolation  nightmare.  Now,  you  are  wondering 
if  hiking  back  across  the  flight  line  only  to  carry  out  another  ten  thousands 
of  manuals  will  actually  identify  the  problem,  or  should  you  take  the  100 
pounds  of  manuals  that  you  have  amassed  at  the  aircraft,  stack  them 
strategically  around  the  problem  aircraft,  and  go  instead  for  lighter  fluid? 

Thanks  to  the  folks  who  envisioned  DoD’s  first,  class  IV IETM,  these 
types  of  problems  will  simply  be”  good  ole  day”  stories  to  tell  new 
maintainers. 

So,  it  is  not  only  the  promises  of  new  technological  innovations  in  computer 
technology,  but  also  some  problems  with  paper  manuals  that  give  a  push  in  the 
development  of  IETMs.  Cost  estimates  for  technical  data  delivered  with  DOD  systems 
range  from  10  percent  to  30  percent  of  total  acquisition  costs  (Pechersky,  1989).  In 
particular,  technical  manuals  consume  large  amounts  of  storage  space  (Masincup  and 
others,  1995).  For  example,  the  B-1B  bomber  has  a  total  of  one  million  pages  of 
documentation.  A  U.S.  Navy  ship  carries  15  to  25  tons  of  manuals.  It  has  been  estimated 
that  if  this  paper  were  removed,  the  ship  would  rise  three  inches  in  the  water  (Pechersky, 
1989). 

A  report  prepared  for  government  identifies  the  problems  with  paper  manuals  in 
the  following  areas  (Ventura,  1987): 

•  Amount,  Weight,  and  Volume 

•  Inaccurate,  Incomplete,  Out-dated  Information 

•  Complex,  and  Disorienting  Information 

•  Less  Portability 

•  Lack  of  Access  to  Information  (Poor  transportability  and  storage  prevent 
needed  documentation  form  being  available  at  a  maintenance  location). 

•  Relying  on  Bad  Information 
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•  Relying  on  Usable  Information  for  Maintenance  (Maintenance  information 
can  become  unusually  complex  and  disorienting). 

Another  report  prepared  by  same  organization  three  years  later  classifies  the 
problem  areas  with  paper  manuals  into  three  groups  (Conway,  1990): 

•  They  are  not  portable 

•  It  is  difficult  to  keep  them  accurate,  complete  and  up-to-date 

•  Needed  information  is  difficult  to  find,  understand  and  use 

There  may  be  other  ways  to  solve  the  first  two  problems,  whereas  the  third 
problem  may  be  solved  by  organizing  information  much  differently  (Conway,  1990).  A 
solution  for  third  problem  is  the  hypermedia  (Conway,  1 990),  and  IETMs  are  based  on 
hypertext  and  hypermedia  (Rivera,  1998).  Hypertext  is  any  text  that  contains  links  to 
other  documents  -  words  or  phrases  in  the  document  that  can  be  chosen  by  a  reader  and 
which  cause  another  document  to  be  retrieved  and  displayed.  A  link  doesn't  just  have  to 
be  text,  however  —  pictures  and  icons  can  also  be  "clickable."  Hypermedia  is  an 
extension  of  hypertext  to  include  graphics,  sound,  video  and  other  kinds  of  data. 

One  may  still  have  questions  whether  the  problems  of  paper  manuals  can’t  be 
really  solved.  Exponential  growth  of  maintenance  data  required  for  supporting  a  modem 
aircraft  is  a  good  example  for  explaining  the  volume  problem  of  paper  manuals  for 
today’s  modem  technological  systems  (Conway,  1990)  (See  Figure  1). 

Web  page  summarizes  the  problems  discussed  above  (NAWCAD  Web  Page, 

1998a): 

The  Navy  was  drowning  in  a  sea  of  paper.  In  1991  a  life  preserver  came  in  the 
form  of  the  AEGIS  RCS  Interactive  Electronic  Technical  Manual  (IETM),  the  first 
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Figure  1.  Exponential  Growth  in  Information  Supporting  Modem  Aircraft  (Conway,  1990) 
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fielded  Navy  IETM.  It  reduced  the  burden  of  bulky,  difficult-to-use  technical  manuals  by 
providing  an  improved  method  for  accessing  technical  information  on  a  PC. 

Do  the  problems  with  paper  manuals  solely  explain  the  need  for  IETMs,  one  may 
ask  what  are  the  benefits  of  IETMs?  Some  benefits  of  IETMs  can  be  summarized  as 
follows  (Advanced  Integrated  Maintenance  Web  Page,  1998): 

•  Multiple  Access  to  Documents 

When  technical  data  is  integrated  into  a  computer  database,  it  is  accessible  for 
multiple  uses  and  applications  (Munguia,  1997).  It  is  possible  that  several 
users  may  reach  the  single  copy  of  technical  documentation  in  a  network 
environment  with  IETM  technology. 

•  Rapid  Search  and  Retrieval  of  Pertinent  Information 

Advanced  search  algorithms  with  today’s  computer  processing  speed 
determine  the  location  of  pertinent  data  very  quickly.  Northwest  Airlines, 
using  a  prototype  system,  experienced  a  minimum  50%  reduction  in  airline 
mechanic's  time  spent  looking  for  the  appropriate  documents.  According  to 
Villecca,  as  also  discussed  by  Tomasetti,  a  technician  spends  30%  of 
maintenance  time  by  searching  for  technical  manuals  (Villecca,  1997:17,  34). 

•  No  Deterioration  Due  to  Handling 

Electronically  rendered  documentation  is  not  subject  to  the  normal  wear  and 
tear  that  is  problematic  to  paper-based  documentation. 

•  Enhanced  Troubleshooting 

Paper-based  documentation  plays  only  a  passive  roll  in  equipment 
troubleshooting.  On-line  access  to  maintenance  information  is  expected  to 
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yield  a  35  percent  improvement  in  trouble-shooting  accuracy  (Pechersky, 
1989).  Studies  show  that  we  retain  50  percent  of  what  we  both  see  and  hear, 
but  up  to  80  percent  of  what  we  interact  with  (Martin,  1995).  Using  artificial 
intelligence  (AI)  methods  embedded  in  the  IETM,  the  documentation  can  take 
an  active  roll  in  maintenance.  DoD’s  class  5  IETMs  is  an  example  of  artificial 
intelligence  embedded  IETMs. 

•  Reduced  Reproduction  Costs 

Electronic  delivery  of  technical  information  provides  substantial  reproduction 
cost  savings  when  compared  to  conventional  paper-based  methods.  The  U.S. 
Air  Force  has  estimated  an  expected  $135  million  annual  savings  in  technical 
manual  savings  (Pechersky,  1989). 

•  Most  Current  Version  Always  Available 

It  is  too  typical  that  an  update  document  will  change  the  technical  procedure 
in  a  technical  document.  Mr.  Holloway,  Air  Force  representative  in  Tri¬ 
service  IETM  working  group,  says  that  it  would  take  210  days  to  make  a 
normal  change  to  technical  documentation  in  Air  Force  with  paper  manuals 
(Holloway,  1998).  Implementation  of  an  IETM  would  allow  updates  at  a 
fraction  of  time.  Using  this  method,  documents  would  always  contain  the 
most  recent  changes  and  additions,  reducing  the  chances  of  lost  man-hours 
due  to  incorrect  information. 

•  Reduced  Weight 

A  typical  document  set  is  approximately  60%  graphics  and  40%  text  and 
tables.  Based  on  these  figures,  a  CDROM  can  store  3400  page  units,  or 
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roughly  20  pounds  of  information.  Each  CDROM,  including  storage  case, 
weighs  approximately  2  ounces;  thus,  the  37  tons  of  paper  carried  by  the 
Aegis  class  ship  could  effectively  be  reduced  to  less  than  1/4  ton  of  electronic 
media,  a  factor  of  1/148. 

•  Reduced  Volume 

The  37  tons  of  paper  aboard  the  Aegis  class  ship  require  approximately  1850 
cubic  feet  of  storage  space.  If  replaced  entirely  with  CDROM,  the  same 
documentation  would  take  up  less  than  35  cubic  feet.  This  savings  more  than 
offsets  any  requirements  that  a  computer  delivery  system  for  the  media  might 
require.  Also,  dedicated  hardware  is  not  absolutely  necessary,  as  office 
automation  computers  could  host  an  IETM  system  with  very  few 
modifications. 

•  Reduced  Combustibility 

Unlike  paper,  magnetic  and/or  optical  storage  media  are  less  likely  to  provide 
fuel  for  a  fire.  Also,  in  the  event  that  this  media  is  involved  in  a  fire,  the 
amount  of  fuel  would  be  significantly  less  than  that  of  paper. 

Another  benefit  of  IETMs  is  the  decreased  maintenance  time  by  eliminating  or 
reducing  the  time  for  removal  and  replacement  of  good  parts  (Munguia,  1998).  IETMs 
are  expected  to  give  more  accurate  and  quick  diagnostics  which  allows  the  technician  to 
go  directly  to  the  malfunctioning  part.  With  IETMs,  it  is  also  possible  to  represent 
different  levels  of  information  from  same  database  to  technicians,  or  to  operators  with 
different  skill  level. 
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Advanced  Integrated  Maintenance,  WWW  summarizes  the  benefits  of  IETM  with 
numbers  (Advanced  Integrated  Maintenance  Web  Page,  1998): 

•  50%  Reduction  in  Time  Spent  Looking  for  Needed  Maintenance  Information 

•  35%  Improvement  in  Troubleshooting  Accuracy 

•  30%  Reduction  in  Reproduction  Costs 

•  Reduction  in  Weight  of  1 48-to- 1 

•  Reduction  in  V olume  of  5  3  -to- 1 

U.S.  DoD  was  one  of  the  first  organizations  that  recognized  the  benefits  of  IETMs 
in  terms  of  decreased  cost  in  getting  technical  data,  and  increased  effectiveness  in  the 
areas  of  maintenance,  training,  and  operations.  There  have  been  many  IETM 
development  projects,  in  accordance  with  DoD  5000.2-R,  throughout  three  military 
organizations,  namely,  Air  Force,  Navy,  and  Army.  Some  of  these  projects  have  been 
IETMs  development  from  legacy  data  of  exiting  systems  in  inventories,  whereas  some 
other  are  based  on  new  systems.  U.S.  DoD  was  also  pioneering  in  the  development,  and 
recognition  of  standards  that  affected  business  in  U.S.  industry  as  well  as  other  countries 
in  the  development  of  IETMs.  However,  little  research  has  been  done  in  industry  about 
IETMs,  especially  in  the  area  of  development. 

Problem  Statement 

This  thesis  will  determine  how  an  Interactive  Electronic  Technical  Manual  is 
developed  in  a  commercial  environment.  It  will  identify  necessary  tasks  to  be 
accomplished  in  the  development  of  an  IETM.  A  case  study  of  an  IETM  development 
project  between  an  IETM  developer  company  and  its  customer  provides  the  basis  for  the 
accomplishment  of  the  below  identified  research  questions. 


Research  Questions 

The  specific  research  questions  are: 

1 .  What  are  the  IETM  development  steps  in  an  IETM  development  project? 

2.  What  are  the  important  considerations  during  each  step  of  the  IETM 
development? 

3.  What  are  the  considerations  that  lead  to  IETM  development  rather  than  paper 
manuals  in  industry? 

4.  How  is  Quality  Control/  Quality  Assurance  program  is  accomplished” 

Need  for  Research 

Being  the  largest  organizations  in  U.S.,  the  military  has  pioneered  development  of 
IETM  concept  and  its  standards.  There  are  lots  of  research  on  the  benefits  of  IETMs, 
effectiveness  of  specific  applications,  and  IETM  related  standards.  However,  there  is  a 
little  research  about  what  civilian  industry  is  doing  about  IETMs,  especially  in  the  area  of 
how  IETMs  are  developed.  This  research  will  determine  what  it  takes  to  develop  an 
IETM  in  an  civilian  project.  It  will  also  identify  important  IETM  development  steps  in 
this  setting. 

Definitions  of  Terms 

A  glossary  of  words  used  in  this  thesis  may  be  found  in  Appendix  A. 

Summary 

Chapter  I  provides  background  to  the  problem,  presents  a  statement  of  the 
problem  to  be  researched,  the  major  research  questions,  and  significance  of  the  research. 
Chapter  II  provides  a  literature  review  of  SGML  and  graphics  standards,  IETM 
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development  steps,  Classes  of  IETMs,  and  today’s  IETM  development  environment.  The 
methodology  used  to  investigate  the  research  questions  outlined  in  Chapter  III.  Chapter 
IV  will  present  the  findings  of  this  case  study  in  Intercept  project,  an  IETM  development 
project  between  O'Neil  &  Associates  and  Cummins  Engine.  Finally,  Chapter  V  presents 
a  discussion  of  the  results,  along  with  recommendations  for  further  research. 


10 


II.  Literature  Review 


Introduction 

As  defined  in  the  DoD  specifications,  an  Interactive  Electronic  Technical  Manual 
(IETM)  is  a  package  of  information  required  for  the  diagnosis  and  maintenance  of  a 
weapon  systems,  optimally  arranged  and  formatted  for  interactive  screen  presentation  to 
the  end-user  (Nawcad  WebPages,  1998b).  Kribs  and  Mark  define  an  IETM  as  an 
electronic  document  that  is  assembled  for  viewing  from  a  database  of  technical 
information  and  can  interact  with  a  technician  to  expertly  maintain  equipment  (Kribs,  and 
Mark,  1995).  Shared  characteristics  of  IETMs  are  (Nawcad  WebPages,  1998b;  Munguia, 
1997:27): 

1 .  The  information  is  designed  and  formatted  for  screen  presentation  to  enhance 
comprehension. 

2.  The  elements  of  technical  data  making  up  the  technical  manual  are 
interrelated.  A  user’s  access  to  required  information  is  possible  by  a  variety  of 
paths. 

3.  The  computer-controlled  technical  manual  display  device  functions 
interactively  (as  a  result  of  user  requests  and  information  input)  to  provide 
procedural  guidance,  navigational  directions,  and  supplemental  information. 

Masincup  adds  three  more  characteristics  to  above  definition  (Masincup  and 
others,  1996:632): 

4.  The  technical  manual  is  in  a  digitized  form  on  a  suitable  medium,  viewed  by 
means  of  an  automated  authoring  system. 
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5.  It  is  designed  for  electronic  display  to  an  end  user. 

6.  Varying  degrees  of  interactivity,  automated  information  links,  graphics 
sophistication,  and  functionality  are  available. 

IETM  concept  is  a  part  of  Continuous  Acquisition  Life-cycle  Support  (CALS) 
concept.  CALS  is  a  DoD  and  industry  strategy  to  enable  the  integration  of  digital 
technical  information,  including  technical  manuals  (TOs),  for  system/equipment 
acquisition,  design,  manufacture,  and  support  (Munguia,  1997:9).  The  primary  goal  of 
CALS  is  to  move  from  paper-intensive  processes  to  integrated  and  automated  processes. 

One  of  the  most  visible  and  mature  elements  of  the  CALS  has  been  the 
development  and  identification  of  electronic  publishing  standards  (Bayne,  1989:73).  The 
following  standards  are  familiar  in  electronic  publishing  sector  (  Bayne,  1989:73;  O'Neil 
&  Associates,  1995a): 

•  Standardized  Generalized  Markup  Language  (SGML) 

•  Computer  Graphics  Exchange  (CGM) 

•  Initial  Graphics  Exchange  Specification  (IGES) 

•  The  Facsimile  Compression  and  Transmission  Standard  (CCITT  Group  4). 

An  IETM  should  contain  digital  chunks  of  information  (text,  graphics, 

precautionary  statements)  linked  to  each  other  in  the  groupings  necessary  to  perform 
specific  tasks  (Delivery  and  Presentation  Committee,  1991:1).  Digital  formats  for 
technical  illustrations  in  CALS  concept  are  described  in  last  three  of  above  standards 
(Munguia,  1997:19),  whereas  SGML  is  metalanguage  (which  based  on  an  international 
standard  ISO  8879),  whose  purpose  is  to  provide  rules  for  managing,  distributing,  and 
publishing  documents  (Kribs,  and  Mark,  1995).  As  discussed  in  “Graphics”  section. 
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graphics  follow  separate  but  parallel  development  steps  with  the  text  in  an  IETM 
development.  These  four  standards  will  be  further  discussed  under  “SGML”,  and 
“Graphics”  section. 

There  are  some  specifications  established  by  military  and  industry  to  standardize 
and  give  direction  to  the  development  of  IETMs.  In  1989,  DoD  established  the  Tri- 
Service  Interactive  Electronic  Technical  Manual  (IETM)  Technology  Working  Group  to 
foster  the  exchange  of  ideas  and  the  agreement  on  a  common  approach,  regarding  the 
acquisition  of  IETMs  which  use  computer  technology  for  the  innovative  display  and 
presentation  of  technical  manual  information  among  all  DoD  agencies  (IETM 
Technology  Working  Group  Web  Page,  1998).  The  group  established  three  military 
specifications  (Fuller,  1997): 

•  MIL-PRF-87268  defines  how  the  IETM  should  look  and  behave  to  the  reader 
(NAWCAD  Information  Technology  Branch  Web  Page,  1998). 

•  MIL-PRF-8L7269  establishes  the  IETM  database  forms,  structure,  and  key 
controlling  mechanisms  (NAWCAD  Information  Technology  Branch  Web 
Page,  1998). 

•  MIL-Q-87270  (cancelled). 

One  other  specification  used  by  the  U.S.  military  is  the  SGML  Implementation 
Guide  (MIL-HDBK-28001).  In  addition  to  standardization  efforts  in  the  military,  some 
industry  organizations  developed  some  specifications  to  guide  IETM  development 
efforts.  ATA  100,  ATA  2100,  and  ASE  J2008  are  familiar  specifications  in  industry. 

AT  A  100  (Air  Transport  Association)  specifies  document  type  definition  to  be 
used  in  by  the  airlines  and  related  manufacturers  at  development  of  technical  manuals. 
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As  opposed  to  the  goals  of  MIL-HDBK-28001  DTDs  which  are  the  interchange  and 
publication  of  data,  the  goals  of  the  ATA-100  DTD  are  the  interchange  and  management 
of  airline  data  (Kusinski,  1991).  Another  specification  developed  by  the  Air  Transport 
Association  is  ATA  2100.  It  establishes  recommended  standards  for  the  presentation  of 
technical  information  prepared  as  digital  media  (magnetic  tape  or  CD-ROM)  produced  by 
aviation  manufacturers  and  used  by  airlines  and  other  segments  of  the  industry  in  the 
maintenance  of  their  respective  products  (Air  Transport  Association  Web  Page,  1998). 

SAE  J2008  is  a  family  of  standards  developed  by  the  membership  of  the  Society 
of  Automotive  Engineers  to  provide  easy  access  to  emission-related  automotive  service 
information.  At  the  heart  of  this  SGML  standard  is  a  relational  Data  Model  for 
Automotive  Service  Information  rather  than  any  particular  document  model.  The  SGML 
definition  set  forth  within  J2008  provides  a  hierarchical  representation  of  the  Data  Model 
(SAE  J2008  Web  Page,  1998).  (A  comparison  of  specifications  for  digital  delivery  of 
technical  manuals  in  military  and  industry  is  given  at  APPENDIX  B). 

It  is  important  to  understand  that  every  IETM  is  different.  The  possible 
characteristics  for  an  IETM  application  are  limitless  (Masincup  and  others,  1996:  633). 
DoD  defines  five  classes  of  IETMs  according  to  format,  display  and  interactivity 
specifications  to  be  used  in  military  IETM  development  applications  (this  topic  is 
discussed  under  “Five  classes  of  IETM”  section).  According  to  the  classification,  an 
IETM  to  be  class  3  and  higher  should  be  developed  in  Standardized  Generalized  Markup 
Language  (SGML)  (Jorgensen,  1994:3).  SGML  concept  is  discussed  under  “SGML” 
section.  SGML  is  welcomed  in  IETM  development  industry  since  it  offers  some  benefits 
other  languages  (markup,  and  word  processing  languages)  can’t. 
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Again,  it  is  important  to  remember  SGML  is  not  the  only  way  to  develop  an 
IETM,  but  the  one  that  is  gaining  more  popularity  and  acceptance  in  the  industry.  For 
example,  Portable  Document  Format  (PDF)  is  also  one  of  the  preferred  formats, 
especially  with  legacy  data.  However,  SGML  is  emphasized  in  this  chapter  since  the 
IETM  development  effort  in  the  case  study  is  accomplished  by  SGML. 

The  rest  of  the  chapter  is  organized  under  following  sections: 

•  Standardized  Generalized  Markup  Language 

•  Graphics  Standards 

•  IETM  Development  Steps 

•  Five  Classes  of  IETM 

•  Today’s  IETM  Development  Environment 

Standard  Generalized  Markup  Language  (SGML) 

What  is  SGML? 

Here  are  some  common  definitions  for  SGML: 

“A  universal  language  necessarily  presupposes  some  basic  or  semantic  primitives 
in  which  the  notions  of  all  other  languages  can  be  expressed”  (Bumard,  1991). 

“SGML  is  an  international  standard  (ISO  8879),  published  in  1986,  for  the 
definition  of  device-independent,  system-independent  methods  of  representing  texts  in 
electronic  form”  (Sperberg,  1998). 

“SGML  Standard,  ISO  8879:1986,  defines  an  abstract  syntax  for  defining  many 
languages.  Since  SGML  is  really  a  method  for  defining  many  languages,  each  Document 
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Type  Definition  (DTD)  potentially  defines  a  different  markup  language;  SGML  itself  is 
often  called  a  meta-language”  (Grosso,  1998). 

What  Makes  SGML  Special? 

There  are  three  characteristics  of  SGML  which  distinguish  it  from  other  markup 
languages:  its  emphasis  on  descriptive  rather  than  procedural  markup;  its  document  type 
concept;  and  its  independence  of  any  one  system  for  representing  the  script  in  which  a 
text  is  written  (Sperberg,  1998). 

Descriptive  markup,  also  known  as  “generic  markup,”  describes  the  purpose  of 
the  text  in  a  document  rather  than  its  physical  appearance  on  the  page.  The  basic  concept 
of  descriptive  markup  is  that  the  content  of  document  should  remain  separate  from  its 
style  (Arbortext  Web  Page,  1995).  By  contrast,  a  procedural  markup  system  defines  what 
processing  is  to  be  carried  out  at  particular  points  in  a  document.  In  SGML,  the 
instructions  needed  to  process  a  document  for  some  particular  purpose  (for  example,  to 
format  it)  are  sharply  distinguished  from  the  descriptive  markup  which  occurs  within  the 
document.  Usually,  they  are  collected  outside  the  document  in  separate  procedures  or 
programs  (Sperberg,  1998). 

With  descriptive  instead  of  procedural  markup  the  same  document  can  readily  be 
processed  by  many  different  pieces  of  software,  each  of  which  can  apply  different 
processing  instructions  to  those  parts  of  it  which  are  considered  relevant  (Sperberg, 

1998).  It  allows  multiple  presentation  of  the  same  information.  For  example,  you  can 
publish  on  paper,  on-line,  on  CD-ROM  and  on  the  World  Wide  Web  (WWW),  all  from 
one  set  of  source  files  (Aheam,  1993:227;  Arbortext  Web  Page,  1995). 
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Secondly,  SGML  introduces  the  notion  of  document  type,  and  document  type 
definition  (DTD).  Documents  are  regarded  as  having  types,  just  as  other  objects 
processed  by  the  computers  do  (Sperberg,  1998).  The  type  of  a  document  is  formally 
defined  by  its  constituent  parts  and  their  structure.  The  definition  of  a  report,  for 
example,  might  be  that  it  consisted  of  a  title  and  possibly  an  author,  followed  by  an 
abstract  and  a  sequence  of  one  or  more  paragraphs  (Sperberg,  1998). 

A  DTD  performs  the  function  analogous  to  that  of  a  grammar:  it  formally  defines 
what  are  the  legal  constituent  parts  of  a  given  markup  (Bumard:  1991 :9).  The 
demonstration  made  at  SGML’ 92  Conference  is  a  good  example  how  different  DTDs  can 
be  created  for  the  same  document.  In  this  exercise,  five  SGML  developers  created  five 
different  DTDs  for  the  literary  magazine,  The  New  Yorker.  This  exercise  demonstrated 
the  importance  of  beginning  the  information  reengineering  process  with  specific  goals 
(Aheam,  1993:228).  Sperberg  emphasizes  the  same  topic  by  stating  that  there  is  no 
single  DTD  which  encompasses  any  kind  of  absolute  truth  about  a  text,  although  it  may 
be  convenient  to  favor  some  DTDs  above  others  for  particular  types  of  analysis 
(Sperberg,  1998). 

Thirdly,  since  both  markup  and  content  in  an  SGML  document  are  presented  in 
the  basic  ASCII  character  set,  SGML  documents  can  be  changed  easily  among  most 
computers  unlike  other  languages  (Gilmore,  1993:211;  Davidson,  1993:406).  This 
feature  is  a  great  strength  of  the  standard  and  offers  the  following  advantages  (Gilmore, 
1993:211): 

•  Markup  that  identifies  information  according  to  its  purpose,  rather  than  its 
format,  enables  it  to  be  used  in  multiple  applications. 
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•  A  single  document  can  be  processed  in  many  different  ways:  formatted  for 
printing,  saved  to  a  database,  displayed  online,  or  combined  with  other  media 
for  mixed-media  displays. 

•  The  use  of  stored  information  is  open-ended.  It  can  be  adapted  for  hypertext 
or  any  other  new  development  that  comes  along. 

•  Information  does  not  become  out  of  date  when  publishing  equipment  or 
programs  are  updated.  In  fact,  information  becomes  independent  of  the 
program  that  created  it. 

How  Does  SGML  Work? 

An  SGML  document  can  be  broken  into  three  layers:  structure,  content,  and  style. 
SGML  separates  these  three  aspects,  but  deal  with  the  relationship  between  structure  and 
content  (Arbortext  Web  Page:  1995).  SGML  has  nothing  to  do  with  setting  standards  for 
style,  so  most  systems  rely  on  proprietary  methods.  Two  efforts  to  develop  standards- 
based  style  sheets  have  resulted  in  (Arbortext  Web  Page:  1995): 

•  Output  Specification  (OS),  which  developed  by  the  U.S.  department  of 
Defense  under  CALS  initiative. 

•  Document  Style  Semantics  and  Specification  Language  (DSSSL),  which  is 
developed  by  the  International  Standards  Organization. 

Munguia  summarizes  how  structure,  content,  style  is  handled  in  SGML 
development  environment:  “The  DTD  provides  the  structure  and  the  FOSI  (DSSSL  in 
industry)  provides  the  output  format  instructions  (style)  while  the  “Tagged  Instance” 
provides  the  content  of  the  final  output”  (Munguia,  1997:15). 
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To:  Students  of  SGML 

From:  Elizabeth  Gilmore 
Date:  January  23, 1993 
Subject:  DTD  for  a  Memo 

A  good  way  to  learn  about  SGML  is  to  use  it,  beginning  with 
simple  documents. 

I  am  sending  you  a  copy  of  the  Memo  DTD.  Please  note  that  the 
following  structural  rules  are  built  into  the  memo  by  the  element 
definitions  (called  declarations  in  SGML): 

•There  can  be  multiple  recipients  and  authors. 

•There  can  be  only  one  date. 

•Providing  a  subject  for  the  memo  is  optional 

•A  body  must  contain  at  least  one  paragraph  (this  element 

•  name  has  been  shortened  to  para) 

•Paragraphs  can  contain  one  or  more  list  items  but  these  are 

•  optional 

I  hope  that  you  enjoy  studying  and  using  this  DTD. 


Figure  2.  The  Document  Memo  (Gilmore,  1993:213) 

An  example  that  explains  how  SGML  deals  with  the  structure  and  content  of  a 
given  document  is  given  below.  As  shown  in  figure  2,  a  memo  document  consists  of  two 
main  parts:  header  and  body.  The  header  has  four  nested  elements  within  it:  recipient, 
author,  date,  and  subject.  The  body,  on  the  other  hand,  contains  three  levels  of  nested 
subelements  since  paragraph  can  contain  lists  and  lists  can  contain  items.  The  tree  model 
of  this  example  is  given  in  figure  3. 

Structure:  As  pointed  out  earlier,  the  structure  of  an  SGML  document  is 
described  by  a  DTD.  (See  the  sample  DTD  for  the  memo  example  in  figure  4).  The 
technical  term  used  in  the  SGML  standard  for  a  textual  unit,  viewed  as  a  structural 
component,  is  element.  Different  types  of  elements  are  given  different  names,  but  SGML 
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provides  of  no  way  of  expressing  the  meaning  of  a  particular  type  element,  other  than  its 
relationship  to  the  other  element  types  (Sperberg,  1 998). 


<!DOCTYPE 

memo  ( 

<!  ELEMENT 

memo  (header, body)> 

<!  ELEMENT 

header  (recipient*,  author+,  date, 

subject?)> 

<!ELEMENT 

recipient  (#PCDATA)> 

<!  ELEMENT 

author  (#PCDATA)> 

<!  ELEMENT 

date  (#PCDATA)> 

<!  ELEMENT 

subject  (#PCDATA)> 

<!  ELEMENT 

body  (para)+> 

<!  ELEMENT 

para  (#PCDATA  1  (list)+)+> 

<!  ELEMENT 

list  (#item)+> 

<!  ELEMENT 

item  (#PCDATA)> 

)> 

Figure  4.  Sample  DTD:  Document  Type  Definition  for  a  Memo  (Gilmore,  1993:214) 
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Each  particular  document,  called  a  “document  instance”  in  SGML  must  always  be 
associated  with  its  corresponding  DTD  in  whichever  computer  system  they  reside 
(Gilmore,  1993:  213).  (See  figure  5).  Within  a  document  instance,  each  element  must  be 
explicitly  marked  or  tagged  in  some  way  (Sperberg,  1998).  Programs  called  “SGML 
parsers”  analyze  and  check  that  the  tagging  in  a  document  instance  satisfies  the  rules 
defined  by  the  DTD  (Gilmore,  1993:213). 


<memo> 

<header> 

<recipient>  Students  of  SGML  </recipient> 

<author>  Elizabeth  Gilmore  </author> 

<date>  January  23,  1993  </date> 

<subject>  DTD  for  a  Memo</subject> 

</header> 

<body> 

<para>A  good  way  to  learn  about  SGML  is  to  use  it,  beginning  with  simple 
documents.</para> 

<para>I  am  sending  you  a  copy  of  the  Memo  DTD.  Please  note  that  the 
following  structural  rules  are  built  into  the  memo  by  the  element 
definitions  (called  declarations  in  SGML): 

<list>  <item>There  can  be  multiple  recipients  and  authors.</item> 
<item>There  can  be  only  one  date.</item> 

<item>Providing  a  subject  for  the  memo  is  optional.</item> 

<item>A  body  must  contain  at  least  one  paragraph  (this  element 
name  has  been  shortened  to  para).</item> 

<item>Paragraphs  can  contain  one  or  more  list  items  but  they  are 
optional  (this  element  name  has  been  shortened  to  para).</item> 

</list> 

</para> 

<para>  I  hope  that  you  enjoy  studying  and  using  this  DTD.  </para> 

</memo> 


Figure  5.  Memo  Document  Instance  (Gilmore,  1993:2 14) 
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Content:  Content  is  the  information  itself.  Content  includes  paragraphs,  lists, 
tables,  graphics,  and  audio.  The  method  for  identifying  the  content’s  position  within  the 
DTD  structure  is  called  “tagging”.  Creating  a  SGML  document  involves  inserting  tags 
around  content  (Arbortext  Web  Page,  1998).  Note  start  and  end  tags  for  each  element  in 
Figure  5. 


SGML  Related  Standards 


XML.  Extensible  Markup  Language  (XML)  is  designed  to  make  it  easy 
and  straightforward  to  use  SGML  on  the  Web:  easy  to  define  document  types,  easy  to 
author  and  manage  SGML-defined  documents,  and  easy  to  transmit  and  share  them 
across  the  Web.  It  removes  two  constraints,  which  are  holding  back  Web  developments 
(Flynn,  1998): 

•  Dependence  on  a  single,  inflexible  document  type  HTML 

•  The  complexity  of  full  SGML,  whose  syntax  allows  many  powerful  but  hard- 
to-program  options. 

The  functionality  of  IETMs  would  be  greatly  enhanced  if  they  had  the 
capability  of  directly  accessing  the  supply  and  ordering  system  directly. 

This  capability  has  been  incorporated  into  a  few  pilot  and  production 
systems;  however,  there  is  not  a  standard  mechanism  for  providing  this 
functionality  and  data  exchange  within  any  IETM  or  SGML 
specifications.  The  current  Internet  XML  initiative  will  allow  the  use  of 
XML  within  existing  SGML/XML  environments  for  on-line  ordering. 

(Harvey,  1998) 


HTML.  Hypertext  Markup  Language  (HTML)  is  a  language  which  is 
used  to  construct  documents  which  can  be  viewed  by  World  Wide  Web  browsers.  It  is  a 
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non-proprietary  format,  based  upon  SGML  and  can  be  created  and  processed  in  a  wide 
range  of  tools  (World  Wide  Web  Consortium  Web  Page,  1998). 

PDF.  Portable  Document  Format  (PDF)  is  the  de  facto  standard  for 
electronic  distribution  of  documents  because  it  keeps  the  look  and  feel  the  user  created 
intact  (Adobe  Web  Page,  1998).  PDF  files  are  compact,  and  cross  platform.  It  is  not  a 
markup  language;  however,  it  is  largely  used  as  an  alternative  to  SGML,  especially  for 
the  conversion  of  legacy  data  into  IETM  applications.  However,  PDF  does  not  support 
the  re-use  and  re-publication  of  information  as  easily  or  as  broadly  as  SGML  does 
(Prettyman,  1996). 

On  the  other  hand,  U.S.  Air  Force  has  chosen  to  convert  the  16  million  pages  of 
legacy  data  (existing  TOs)  to  Indexed  Portable  Document  Format  in  April  1995(Air 
Force  Product  Data  Modernization  Office  Web  Page,  1998).  The  one  possible 
explanation  for  this  it  that  the  costs  entailed  by  conversion  may  overweigh  the  benefits 
expected. 

Graphics 

In  an  SGML  document,  the  graphic  would  be  incorporated  by  reference  rather 
than  embedded  in  the  text.  This  would  allow  for  separate  file  storage  and  maintenance, 
perhaps  in  a  CAD\CAM  tool,  and  production  of  multiple  versions  for  various  delivery 
systems  (Davidson,  1993:405).  Thus,  graphics  and  images  require  their  own  specialized 
translation  and  compression  programs  (Glushko,  1993:394).  IGES,  CCITT-G4,  and 
CGM  are  three  graphic  standards  for  CALS  compliant  data  (Bayne,  1989:73;  Electro- 
Tech  International  Corporation,  1990a:  1-2;  O'Neil  &  Associates,  1995b;  Knox,  1993). 
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IGES,  which  stands  for  Initial  Graphics  Exchange  Specification,  is  a  standard  for 
exchanging  3-D  vector,  CAD  type  data;  primarily  used  for  translating  engineering 
drawings  into  digital  form.  (Electro-Tech  International  Corporation,  1990a:  1-2; 
O'Neil&Associates,  1995b). 

CCITT  is  acronym  for  Consultative  Committee  on  International  Telephony  and 
Telegraphy.  CCITT-G4  is  an  international  standards  body  concerned  with 
telecommunications.  It  is  a  raster  standard  used  for  fax  transmissions  and  scanned 
images  (O'Neil  &  Associates,  1995b). 

CGM,  which  stands  for  Computer  Graphics  Metafile,  is  a  standard  that  is  widely 

used  for  all  types  of  technical  illustrations.  CGM  files  can  include  raster  graphics,  vector 

graphics,  or  combination  thereof.  Although  all  three  graphics  are  CALS  compliant, 

CGM  offers  a  distinctive  approach  (O'Neil  &  Asscoiates,  1995b). 

According  to  O'Neil  &  Associates,  Government  and  Industry  groups  throughout 

the  world  such  as  the  ATA  and  CALS  are  viewing  CGM  as  the  ideal  companion  standard 

to  SGML  for  integrated  text  and  graphics  authoring,  management  and  publishing  systems 

(O'Neil  &  Associates,  1995b).  Munguia  also  states  that  CGM  is  the  preferred  format  for 

digital  TO  illustrations  in  U.S  Air  Force  (Munguia,  1997:19).  Harvey  explains  the 

ineffectiveness  of  CALS  graphics  standards  as  follows: 

IETMs  deployed  today  use  various  types  of  graphic  formats  and  styles. 

Although  graphic  standards  have  been  specified  in  several  industry 
standards,  including  CALS  and  the  Airline  Transportation  Association 
(ATA)  2100  most  IETMs  don't  use  or  support  these  standard  graphic 
formats.  As  a  result  of  the  ineffectiveness  of  the  CALS  standards  current 
IETMs  within  CALS  programs  usually  use  other  graphic  standards  or  no 
standards  at  all.  (Harvey,  1998) 
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Vector  vs.  Raster  Images 

Raster  images  may  come  from  scanners  and  paint  programs.  The  key  to  raster- 
based  systems  is  that  the  software  package  create  the  illustration  by  laying  down  “dots” 
(turned  “on”  or  “off’  to  draw  the  image)  to  create  the  image  (Electro-Tech  International 
Corporation,  1990a:  1-5).  Raster  images  are  presented  as  a  matrix,  or  grid,  or  tiny  black 
and  white  dots  (300  to  1200  dots  per  inch).  These  black  an  white  patterns  are  represented 
as  binary  data.  Because  both  the  background  and  the  image  must  be  stored,  raster  images 
can  be  quite  large.  When  raster  images  are  reduced,  some  of  the  dots  are  dropped  and  the 
images  can  lose  detail.  Enlarged  raster  images  can  become  jagged  and  blocky  (O'Neil  & 
Associates,  1995b). 

Vector  graphics  systems,  such  as  Computer-Aided  Design  (CAD)  equipment, 
operate  very  differently  from  raster  (Electro-Tech  International  Corporation,  1990a:  1-5). 
With  vector  images,  vector  data  represents  lines,  directions,  distances,  and  geometric 
formulas.  The  letters  and  numbers  of  the  type  fonts  are  also  represented  by  the  vector 
data  (O'Neil  &  Associates,  1995b).  Thus,  vector  systems  offer  the  user  abilities  such  as 
moving  an  object  around  or  deleting  it  in  its  entirety,  exploding  or  shrinking  an  object, 
rotating  it  (especially  valuable  when  operating  a  3-D  vector  system)  (Electro-Tech 
International  Corporation,  1990a:  1-6). 

IETM  Development  Steps 

As  discussed  earlier  in  this  chapter,  IETM  development  is  mainly  based  on 
SGML.  In  the  literature,  the  conversion  of  legacy  data  into  SGML  is  called  as  “  up- 
translation,  whereas  conversion  from  SGML  into  any  other  format  called  “down- 
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translation”  (Balise  Web  Page,  1998;  Pepper,  1994;  Information  Architects  Web  Page, 
1998). 

The  terms  “up”  and  “down”  come  from  the  idea  that  an  SGML  document  base  is 
designed  to  model  the  suitable  level  of  information  for  a  given  project.  It  corresponds  to 
the  “highest”  level  of  information.  Going  from  this  level  of  information  to  any  other 
(publication)  structure  is  therefore  a  down-translation,  whereas  going  from  legacy 
formats  to  this  level  is  an  up-translation  (Balise  Web  Page,  1998:1). 

It  is  important  to  remember  that  every  conversion  process  is  different 
(Information  Architects  Web  Page,  1998).  Up-translation  can  only  be  characterized  on  a 
case  by  case  basis.  The  number  of  possible  source  formats  is  very  large,  but  among  all, 
an  up-translation  project  is  driven  by  the  distance  between  legacy  documents  structure 
and  the  target  SGML  structure  (Balise  Web  Page,  1998). 

Down  translation  can  be  defined  and  formally  specified  as  a  structure-to-structure 
mapping,  because  the  source  of  the  transformation  is  a  formal  (SGML)  structure.  Down- 
translation  processes,  although  some  of  them  can  be  quite  complex,  are  thus  very  stable 
and  reliable  processes  (Balise  Web  Page,  1998).  A  typical  example  of  “down- 
translation”  is  the  conversion  of  data  from  SGML  format  into  HTML  format. 

A  cross  translation  will  occur  when  there  is  an  SGML  document  that  uses  DTD 
“A”  and  now  DTD  “B”  is  the  preferred  form  (Information  Architects  Web  Page,  1998). 

After  this  brief  broad  introduction  to  “up”  and  “down”  translation  in  SGML,  it  is 
going  to  be  explained  what  it  takes  to  develop  an  IETM.  However,  there  is  not  a  formal 
set  of  steps.  Different  sources  refer  same  processes  and  functions  in  the  development 
process  with  different  names.  In  this  section,  different  ways  of  doing  things  in  the  case  of 


different  scenarios  are  going  to  be  explained  instead  of  trying  to  find  a  formal  way  doing 
a  specific  task. 

The  following  discussion  about  IETM  development  steps  is  organized  as  follows: 

•  Preplanning 

•  Conversion  Process 

•  Input  Documents 

•  Conversion  Itself 

•  Enrichment  of  Technical  Information 

•  Quality  Control 

•  Database  Management 

•  Deployment 

Preplanning 

A  successful  SGML  implementation  requires  forethought  and  planning  in  two 
important  aspects,  firstly  in  the  specification  of  general  system  goals  and  requirements, 
and  secondly,  in  the  concrete  phase  of  document  analysis  and  DTD-design  (Pepper, 
1994).  Before  going  to  planning  and  conversion  process,  it  is  important  to  make  it  sure 
that  the  data  conversion  for  legacy  information  was  both  possible  and  affordable  (Wood, 
1997:27).  This  task  often  refer  to  “proof  of  concept”  (Wood,  1997:27;  Information 
Architects  Web  Page,  1998;  Gross,  1995). 

The  characteristics  possible  for  an  IETM  application  are  limitless,  but  must  be 
defined  prior  to  beginning  the  development  process  (Masincup  and  others,  1996:  633). 
Items  which  must  be  defined  (Masincup  and  others,  1996:  633): 

•  Goal  of  application  (instruction,  information,  reference,  or  a  combination). 
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•  Level  of  interactivity  (text  links,  graphics  links,  level  of  user  response, 
situational  simulations,  etc.) 

•  Graphics  (line  drawings,  color,  use  of  three-dimensional  models,  animations, 
video,  photographs,  etc.) 

•  Simulations,  if  any  (animations,  video,  sound,  etc.) 

•  Hardware  limitations,  if  any  (will  existing  hardware  be  used  or  an  new 
hardware  be  defined?). 

A  case  study  about  the  Tornado  F3  IETM  development  efforts  also  identifies  the 
importance  of  the  implications  of  output  specifications  in  IETM  development  (Wood, 
1997:30).  DoD  specifies  five  classes  of  IETMs,  in  military  projects,  according  to  data 
format,  display,  and  functionality  requirements  (Masincup  and  others,  1996:  633).  There 
is  not  such  a  formal  classification  of  IETMs  in  industry.  However,  IETM  classes 
developed  by  DoD  is  a  good  reference  to  be  used  by  industry.  This  subject  is,  later, 
further  discussed  under  the  section  “Five  Classes  of  IETM”. 

Overall,  the  important  thing  to  understand  about  SGML  applications  is  that  they 
are  not  all  the  same.  There  is  actually  no  such  thing  as  “converting  to  SGML”,  only 
converting  to  a  specific  application  (Grosso,  1998). 

SGML  applications  are  always  based  on  a  specific  DTD.  Here  are  the  some  of  the 
question  should  be  asked  while  developing  a  DTD  (Grosso,  1998): 

•  What  kinds  of  document  exist,  and  what  common  classes  of  documents  can  be 
identified? 

•  What  are  the  basic  structural  components  and  other  logical  objects  that  occur 
within  each  document  type? 
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•  In  addition  to  text  content,  what  other  information  or  properties  might  be 
assigned  to  each  obj  ect  type? 

•  What  are  logical  relationships  between  each  of  the  objects? 

•  What  do  you  want  to  do  with  your  information?  What  are  the  kinds  of 
structures  and  relationships  that  you  are  wanting  to  encode  in  SGML  in  order 
to  drive  electronic  document  delivery,  document  management,  and  other 
benefits  that  are  motivating  SGML  conversion  in  the  first  place? 

The  analysis  of  legacy  data  is  performed  to  determine  what  kind  of  format  the 
initial  documents  are  in  (Severson,  1998;  Pepper,  1994).  This  task  involves  matching  up 
the  input  to  the  kinds  of  information  elements  and  relationships  assumed  in  the  SGML 
application.  In  this  case  some  of  the  question  that  should  be  asked  are  (Severson,  1998): 

•  What  form(s)  input  at  hand  (hardcopy  or  electronic,  etc.)?  What  are  the 
graphics,  equations  and  other  formats  that  may  need  additional  conversion? 

•  How  “structured”  is  the  input?  That  is,  how  much  explicit  encoding  of 
structural  objects,  row/column  tables,  links,  etc.  is  already  available?  How 
consistently  have  these  conventions  been  followed? 

•  How  do  the  “objects”  (visually  or  explicitly  encoded)  in  the  input  document 
relate  to  the  objects  in  the  target  SGML? 

Conversion  Process 

According  to  Gross,  conversion  is  an  important  issue  because  you  are  rarely 
starting  anew  (Gross,  1993:219). 
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Input  Documents.  The  form  of  the  input  can  make  a  big  difference  in  the 
selection  of  suitable  conversion  approach.  Figure  6  represents  information  in  different 
forms.  The  higher  in  the  chart,  the  more  effort  is  required  to  infer  the  information  for 
SGML  conversion  (Gross,  1993: 221). 


handwritten 
microfilm 
typed  or  printed 
ASCII 

word  processing  (no  styles) 
typesetting  (no  tags,  macros) 
word  processing  (styles) 
typesetting  (tags,  macros) 

SGML-like  tagged  text 
structured  databases 
SGML 

Figure  6.  The  “Ease  of  Conversion”  Hierarchy  (Gross,  1993:219) 

Severson  says  that  hardcopy  is  the  hardest  place  to  start  (Severson,  1 998).  The 
first  step  in  converting  hardcopy  to  SGML  is  getting  text  into  digital  form.  This  can  be 
done  by  manual  rekeying,  or  automated  by  Optical  Character  Recognition  (OCR) 
scanning.  According  to  a  case  study  done  by  Army,  accuracy  rates  of  99+%  are 
reasonable  targets  and  obtainable  with  OCR  scanning  (Electro-Tech  International 
Corporation,  1990b:4-2).  With  hardcopy  documents,  all  structure  is  visual.  There  is  no 
underlying  encoding  to  translate  to  SGML.  OCR  errors  can  multiply  the  effect  of  errors 
in  the  conversion  process  (Severson,  1998).  Therefore,  for  all  scanned  materials  you 
must  have  a  human  review  (Gross,  1993:223).  Graphics  and  equations  are  available  only 
in  raster  format  and  have  their  own  set  of  parallel  conversion  issues  (Severson,  1998). 
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Conversion  to  SGML  is  a  lot  easier  when  input  has  been  authored  in  electronic 
form  (Severson  1998).  The  advantage  of  using  electronic  formats,  even  those  “ugly” 
typesetting  formats,  is  that  the  text  will  transfer  accurately,  and  if  the  tapes  are  correct, 
the  text  accuracy  is  100%  (Gross,  1993:223).  However,  electronic  format  is  deceptive 
(Severson  1998).  The  way  in  which  material  is  coded  is  not  necessarily  the  way  you 
would  have  expected,  and  therefore  the  document  will  not  necessarily  convert  the  way 
you  expect  that  it  should  (Gross,  1993:223). 

As  discussed  earlier,  sometimes  systems  requirement  may  necessitate  the 
conversion  of  data  from  a  DTD  to  another  DTD.  These  kinds  of  conversions  may  be 
simple  or  complex  depending  upon  DTD  that  the  data  is  in  and  which  DTD  the  data  is 
being  transformed  to  (Information  Architects  Web  Page,  1998). 

While  creating  an  IETM  from  scratch,  data  should  be  authored  in  SGML.  In 
SGML  authoring,  the  basic  operation  consists  of  building  a  structure  from  object 
identifiers  (tags)  or  typing  into  a  predefined  element  structure  (Davidson,  1993:405). 
With  the  first  case,  a  standard  character-based  editor  such  as  some  word  processor  in 
“ASCII”  mode  to  author  both  text  and  markup  can  be  used;  whereas  with  the  second  case 
an  SGML-aware  editor  provides  automatically  or  through  some  non-character  based 
interface  the  proper  markup  (Grosso,  1998). 

Overall,  while  selecting  source  materiel  it  is  important  to  take  into  account 
(Gross,  1993:222-223): 

•  The  ease  of  conversion 

•  The  accuracy  of  the  information 

•  Version  integrity 
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Text  integrity 


Conversion.  The  text  portion  of  a  document  contains  three  categories  of 
information,  in  order  of  increasing  conversion  difficulty  (Gross,  1993:221). 

•  Data,  text  and  numbers-  are  relatively  easy  convert  automatically. 

•  Structural  information-is  inferred  from  the  structure  of  the  document. 

•  Content-based  information-  requires  an  understanding  of  the  topic  area 
Figure  7  depicts  various  components  of  typical  documents.  Each  component 

blends  of  the  three  types  of  information,  and  is  dealt  with  in  a  different  manner  (Gross, 
1993:222). 


Documents  level  information 
(footers,  headers,  etc.) 
Headings  and  subheadings 
Paragraphs 
Lists 
Tables 

Special  characters 
Graphics 
Equations 
Cross-references 
Content  tagging 


Figure  7.  Various  Components  of  Typical  Documents  (Gross,  1993:  221) 


The  primary  aim  of  the  conversion  process  is  to  make  explicit  structure,  which 
already  exist  implicitly  in  the  source  document.  The  kinds  of  structural  clues  that  may  be 
picked  by  and  used  by  an  up-translation  system  are  threefold  (Pepper,  1994). 
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•  Visual  attributes:  Elements  can  be  differentiated  from  one  another  by  the  way 
they  are  placed  on  the  page.  For  example,  paragraphs  may  be  separated  by 
blank  lines  or  marked  by  first  line  indents. 

•  Generic  codes:  Documents  that  come  from  a  text  processing  system  may 
already  contain  some  form  of  generic  markup  that  offer  clues  as  to  their 
structure.  For  example,  chapter  heads  may  be  encoded  as  “\chapter”  {Title  of 
chapter}  in  a  TeX. 

•  Textual  patterns:  Some  elements  may  be  recognized  on  the  basis  of  recurring 
textual  patterns.  For  example,  a  chapter  heading  may  be  preceded  by  the 
word  “Chapter”  followed  by  a  number. 

It  is  quite  often  that  common  production  techniques  are  not  viable  due  to  different 
publishing  techniques  have  been  used  over  years  (Wood,  1997:28).  Getting  data  into 
SGML  may  be  achieved  in  number  of  ways  (Pepper,  1994): 

•  Direct  authoring 

•  Keyboarding  from  a  manuscript 

•  Generating  from  some  other  structured  source,  such  as  a  database  or 
spreadsheet 

•  Scanning  from  a  printed  source  using  optical  character  recognition 

•  Translating  from  an  unstructured  electronic  source 

In  general  conversion  can  be  either  manual  or  software  assisted  (Severson,  1998; 
Gross  1993:222).  Figure  7  illustrates  the  cost  of  conversion  with  respect  to  manual  and 
automated  conversion.  As  can  be  guessed  from  the  figure,  there  is  an  overhead  (initial 
cost)  to  set  up  automated  conversions,  whereas  variable  cost  drops  quickly. 
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Number  of  pages 

Figure  8.  Chart  for  Relative  Conversion  Costs  (Gross,  1993:221) 


Enrichment  of  Technical  Information.  SGML  is  one  of  the  most 
prominent  among  those  languages  that  are  being  used  to  “mark  up”  documents  to  insert 
information  in  the  documents  in  addition  to  the  normal  text  (Sengupta,  1998).  IETM  may 
present  the  user  different  kinds  of  data  that  are  not  available  with  conventional  paper 
manuals.  As  discussed  in  Chapter  I,  Conway  categorizes  problems  with  paper  manuals 
into  three  groups.  One  group  is  the  difficulty  in  finding  and  understanding  the  technical 
information.  According  to  Conway,  only  way  to  solve  this  problems  is  the  hypermedia 
(Conway,  1990),  and  IETMs  are  based  on  hypertext  and  hypermedia  (Rivera.  1998). 

You  can  enrich  technical  data  in  a  variety  of  ways  by  using  hypertext  and  hypermedia 
such  as  by  adding  pop-up  menus,  audio  files,  and  video  files.  You  can  add  data  base 
hooks  to  other  related  information  such  as  other  databases,  and  complementary 
information  (warranty,  and  service  information  etc.).  Hypertext  and  hypermedia 
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information  which  may  explicit  or  implicit  in  technical  data  must  be  captured  in 
document  analysis. 

A  report  prepared  for  DoD  summarizes  and  differentiates  IETM  data  into  two 
groups.  First  group  includes  different  types  of  technical  data,  whereas  second  group 
includes  types  of  information  related  to  the  use  of  IETMs,  but  not  part  of  the  content 
(Delivery  and  Presentation  Committee,  1991:3-1). 

1 .  Technical  data  itself 

•  Diagnostics/Fault  Isolation.  Automatic  and  manual  trouble  shooting  and 
fault  isolation,  battle  damage  assessment,  including  expert  systems 

•  Procedural.  Remove,  replace,  checkout,  checklists,  operating  instructions, 
fault  isolation 

•  Descriptive.  Theory,  principles  of  operation 

•  Precautionary.  Warnings,  cautions,  notes,  safety  summaries 

•  Graphics 

•  Parts.  Parts  numbers,  reference  designators 

2.  Types  of  information  related  to  the  use  of  IETMs,  but  not  part  of  content. 

•  Indexing.  Menus,  lists  of  contents,  and  key  words 

•  Identifiers  (ID).  Titles,  classifications,  and  numbering 

•  Look-up  tables 

•  Maintenance  and  operations  management.  Data  collection,  feedback, 
scheduling,  and  audit  trails 

•  Glossary 

•  On-line  help 
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Built-in-test  data  from  prime  or  test  equipment 


Quality  Control.  All  SGML  authoring  systems  must  include  a  parser 
(Davidson,  1993:407;  Gilmore  1993:213).  One  of  its  uses  is  validation  and  checking,  and 
it  enables  the  user  to  validate  that  the  document  conforms  to  rules  of  its  DTD  and  to  the 
rules  of  SGML  itself  (Davidson,  1993:408).  The  ISO  technical  report  TR10037  (1991), 
as  also  discussed  by  Davidson,  distinguishes  among  static,  dynamic,  and  partial 
validation  (Davidson,  1993:408). 

•  Static  validation  means  checking  for  errors  “at  the  end  of  the  creation  or 
modification  process  or  on  specific  user  request.” 

•  Dynamic  validation  means  that  the  user  is  guided  by  the  program  in  the 
editing  process  in  such  a  way  that  errors  may  not  be  inserted. 

•  Partial  validation  allows  the  user  to  begin  document  creation  at  the  paragraph 
level  and  still  have  the  benefit  of  validation  for  the  paragraph  without  the 
parser  prompting  for  missing  chapter  tags  or  require  chapter  title. 

According  to  Severson,  against  the  common  belief  quality  control  is  synonymous 
with  SGML  parsing,  there  are,  actually,  at  least  three  critical  dimensions  of  quality 
control  (Severson,  1998:9): 

•  Syntactic  correctness:  making  sure  it  parses, 

•  Semantic  correctness:  making  sure  tags  actually  correspond  to  the  correct 
objects,  with  beginnings  and  ends  at  the  correct  spots, 

•  Tagging  completeness:  making  sure  any  information  that  is  important  to  the 
document  is  not  missed 
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Database  Management 

The  trend  in  technical  documentation  systems  is  toward  a  database  management 
approach  where  information  is  organized  and  managed  as  logical  units  (Waldt,  1993). 
Increasingly  SGML  data  is  being  stored  in  databases,  where  access  to  the  stored  data  is 
being  controlled  at  the  levels  below  of  that  of  a  complete  file/document/message 
(ISO/IEC  JTC1/WG4  N1946  Web  Page,  1998).  At  the  conceptual  level  database  systems 
can  be  distinctively  categorized  under  the  following  three  generations  of  database 
systems  (Sengupta,  1993): 

1 .  First  Generation:  Hierarchical  and  Network  Databases 

2.  Second  generation:  Relational  Databases 

3.  Third  generation:  Object-oriented,  Object-relational  databases 

In  terms  of  data  storage  and  information  management,  users  seem  to  have  three 
choices  -  they  can  stick  with  the  established,  performance-optimized  relational  databases, 
opt  for  the  emerging  (but  still  untested)  capabilities  of  object  oriented  database  systems, 
or  take  a  middle  path  by  buying  a  hybrid  database  (McNamara,  1998). 

Relational  databases  are  excellent  at  handling  (storing,  retrieving,  and  analyzing) 
alphanumeric  data.  They  are  not  as  adept  at  handling  variable  length  data,  such  as  text, 
scanned  images  imported  from  paint  or  drawing  programs,  or  large  bitmap  images 
CAD\CAM  files  (Dewire,  1994:1 14).  In  addition,  SQL,  the  industry  standard  retrieval 
language  for  relational  databases,  can  not  manipulate  binary  large  objects  (BLOBs).  On 
the  other  hand,  object-oriented  databases  are  beginning  used  to  effectively  store  and 
retrieve  BLOBs  which  are  used  much  more,  especially  in  multimedia  (Dewire  1994:1 14). 
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According  to  McNamara,  although  not  specifically  technical,  a  technology 
strategy  that  is  inclusive  -  one  that  employs  Object-Oriented  document  management 


functionality  layered  on  a  conventional  relational  database  is  the  best  approach  to  store 
and  manage  the  information  in  databases  (McNamara,  1998). 

Class  4  and  class  5  IETMs  ,  as  it  is  discussed  under  “Five  classes  of  IETMs” 
section,  require  the  use  of  databases  to  manage  the  information  (Jorgensen,  1994:  6-7). 
Wood  gives  a  good  example  of  database  management  in  Tornado  F3  project.  The  project 
uses  an  SGML-based  data  module  concept  complying  with  European  Aerospace 
Documentation  Specification  (AECMA)  1000D  (Wood,  1997:29).  Information  Codes 
defined  in  the  AECMA  1000D  specification  identify  the  type  of  information  contained 
within  the  data  module-  servicing,  examination,  failure,  reporting,  repair,  removal  and 
installation,  storage  etc.  Each  module  can  be  put  into,  and  retrieved  from  a  database 
using  a  data  module  code  (DMC)  as  identifier. 

Deployment 

The  deployment  is  the  last  stage  of  producing  an  IETM  development.  The 
information  which  is  in  SGML  format  should  be  delivered  to  the  end-user.  It  may  be 
delivered  in  SGML  format,  HTML,  other  markup  languages,  or  word  documents.  Pepper 
identifies  three  different  deployment  categories  (Pepper,  1994): 

•  SGML  based  systems-  the  software  directly  operates  on  the  SGML  document 
itself.  Such  systems  will  usually  employ  some  standardized  way  of  specifying 
how  to  apply  processing  to  the  document  type,  e.g.  using  a  FOSI  or  methods 
defined  in  ISO  10179  (DSSSL). 


•  Quasi-SGML  systems  -  these  systems  do  not  directly  operate  on  the  SGML 
instance  itself,  but  are  able  to  import  and  export  SGML  documents  to  and 
from  the  system’s  own  internal  representation. 

•  Non-SGML  systems-  the  using  software  that  knows  nothing  at  all  about 
SGML  itself  is  the  most  common  way  of  laying  out  SGML  documents.  In 
order  to  use  non-SGML  systems,  the  SGML  documents  must  be  transformed 
into  a  different  notation  such  as  a  specific  markup,  or  proprietary  “tagging 
language”  associated  with  a  desktop  publishing  program. 

A  wide  variety  of  tools  can  be  used  for  displaying  SGML  data.  Generally,  they 
fall  into  three  classes  (Conrad,  1998): 

•  Readers:  are  used  to  display  the  contents  of  files  without  any  interpretation  or 
rendering. 

•  Viewers:  add  interpretation  and  rendering  capabilities  but  base  most  of  their 
rendering  on  metadata  (formatting  codes)  which  were  designed  to  support  the 
printing  of  paper  hard  copy. 

•  Browsers:  abandon  the  page  metaphor  to  provide  an  electronic  delivery 
environment  that  is  more  in  tune  with  the  capabilities  and  constraints  of 
computer  displays. 

In  IETM  development  environment,  the  most  popular  forms  to  deploy  IETMs  to 
the  hands  of  user  are  in  a  CD-ROM  or  on  World  Wide  Web  (WWW).  Both  technologies 
and  the  tools  using  them  are  rapidly  increasing  in  functionality  and  accessibility  and  this, 
in  turn,  continues  to  expand  the  types  and  numbers  of  applications  developed  in  IETM 
development  environment  as  well  as  in  most  areas  of  our  life  (Kribs  and  Mark,  1995). 
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There  are  important  differences  (pros  and  cons)  between  these  two  channels  for 
deployment  of  IETMs. 

CD-ROM  publishing  and  viewing  software  requires  some  sort  of  licensing  cost 
and  legal  arrangement  for  distribution.  Hardware  is  another  issue.  Designing  a  CD  for 
multiple  platforms  such  as  PC,  Mac,  and  Unix  may  require  the  help  of  a  consultant 
specializing  in  system  migrations.  On  the  other  hand,  one  advantage  to  CD-ROM  over 
on-line  publishing  is  that  it  is  not  restricted  to  the  logical  structure  inherent  in  Hypertext 
Markup  Language  (HTML).  Moreover,  there  are  more  formatting  options  available  on 
CD-ROM  and  production  is  ideal  for  large  and  complex  projects  that  contain  elaborate 
tables,  equations,  and  formatting  structures  (O'Neil  &  Associates,  1997c:  2-3). 

The  WWW  publishing  allows  the  user  easy  access  to  information.  TCP/IP 
(Transmission  Control  Protocol/Intemet  protocol)  allows  for  seamless  integration  with  all 
system  platforms.  Thus,  issues  concerning  individual  access,  network  access,  platform 
compatibility  and  licensing  fees  are  no  longer  factors.  Both  data  and  interface  can  be 
modified  very  quickly  with  online  publishing.  Hence,  the  target  audience  receives  the 
latest  data.  Unlimited  worldwide  resources  can  be  incorporated  in  the  publications  by 
simply  providing  links  to  them  and  distribution  costs  are  eliminated  (O'Neil  & 

Associates,  1997c:  2-3). 

Five  Classes  of  IETMs 

The  variances  in  electronic  presentation  form  and  the  ranges  of  embedded 
functionality  have  resulted  in  a  very  broad  spectrum  of  electronic  technical  manual 
implementations  making  discussion  and  comparison  of  alternate  systems  and  approaches 
difficult  (Navy  CALS  Web  Page,  1998).  Tri-Service  Working  Group  for  IETMs 
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developed  five  classes  of  technical  manuals  for  DoD  with  the  proviso  that  it  be  used  for 
definition  only  and  not  as  an  specification  for  procurement.  These  five  classes  of  IETM 
are  explained  below  (Jorgensen,  1994:2-7): 

Class  0. 

Non-electronically-Indexed  Page  Images  (Not  an  ETM)  -  “Systems  of  Digitized 
Page  Images  that  are  intended  for  electronic  archival  filing  or  Print-on-Demand.  These 
allow  pages  to  be  viewed  on  an  electronic  display  but  have  no  detailed  index  for 
navigation  through  the  document  for  purposed  of  on-line  usage.  (Page  4). 

Class  1. 

Electronically  Indexed  Page  Images  -  Systems  of  Digitized  Page  Images  intended 
for  Full-Page  Display  and  use  allowing  navigation  by  means  of  an  automated  intelligent 
index  to  the  page  images  for  user  access  (Jorgensen,  1994:4-5).  The  primary  purpose  of 
the  technical  manuals  in  this  class  is  to  print  a  paper  manual  on-demand  and  thus 
eliminate  the  need  to  stock  the  paper  manuals  before  they  actually  needed  (Villecca, 
1997:15). 

Class  2. 

Electronic  Scrolling  Documents  -  Systems  for  Interactive  Display  of  ASCII 
encoded  Documents  using  an  intelligent  index  and  Hypertext  tags  inserted  into  tagged 
document  file.  In  general,  the  document  is  the  result  of  a  simple  conversion  from  a  page- 
oriented  document  but  with  little  reathouring  with  the  exception  of  adding  hypertext  tags 
(Page:  5). 
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Class  3. 


Linear  Structured  IETMs  -  Interactive  Display  of  technical  Information  which  is 
SGML  tagged  using  MIL-D-87268  tags  to  the  maximum  extent  possible  and  using  a 
Hypertext  presentation  system  for  display  in  accordance  with  MIL-M-87268.  Class  3  is 
the  class  in  which  the  TM  authoring  organization  has  an  opportunity  to  reorganize  for 
electronic  presentation,  augment  and  convert  an  existing  manual  into  an  IETM  data- 
element  form  in  order  to  increase  technician  performance  by  better  access  and  display  of 
information,  as  well  as,  provide  the  benefits  achieved  by  eliminating  paper  (Page:  5-6). 

Class  4. 

Hierarchically  Structured  IETMs  -  Interactive  Electronic  Display  of  Technical 
Information  specifically  authored  into  and  maintained  in  a  non-redundant  relational  or 
object-oriented  hierarchical  database.  These  source  data  are  subsequently  packaged  (i.e., 
“view  packaged”)  as  a  run-time  database  for  Interactive  Presentation  in  accordance  with 
the  DoD  IETM  Specifications  (MIL-M-87268,  and  MIL-D87269).  Class  4  Systems 
(IETM)  are  those  for  which  the  TM  data  was  specifically  authored  into  a  non-redundant 
hierarchical  data  base  form,  using  a  data  base  management,  system  for  the  total  content 
(Page:  6). 

Class  5. 

Integrated  Data-Base  IETIS  -  Integrated  Electronic  Technical  Information  System 
(IETIS)  for  Interactive  Presentation  of  Class  4  IETMs  integrated  in  with  the  data  for  other 
processes  including  Expert-system  rules  for  the  display  of  information  and  other  user- 
applications  such  as  diagnostics  or  computer-managed  training  (Page:6-7). 
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To  summarize  interrelationships  between  these  five  classes,  at  the  user- 
presentation  level.  Classes  3  through  5  can  show  almost  identical  features.  However, 
Classes  1  and  2  are  after-the-fact  preparation  systems  while  classes  3  through  5  involve 
technical  manuals  prepared  of  reauthored  by  the  authoring  organization.  Classes  1,2  and 
3  involve  encoding  a  linear  document  with  its  existing  section  after  section  structure, 
whereas  Classes  4  and  5  employ  the  use  of  information  extracted  from  a  managed 
hierarchically  structured  database  and  compiled  into  a  form  optimized  for  interactive 
screen  presentation  (Jorgensen,  1994:7). 

These  five  classes  are  tabulated  at  table  to  according  to  their  features  in  the  areas 
of  display,  data  format,  and  functionality  at  Appendix  C. 

IETM  classifications  should  not  be  considered  as  constraints  on  a  development 
process.  It  is  more  advantageous  to  begin  by  defining  the  functions  needed  in  a  specific 
IETM  and  tailoring  the  development  process  to  the  need  rather  than  selecting  a  class  that 
may  or  may  not  meet  application  needs  (Masincup  and  others,  1996:632). 

Today’s  IETM  Environment 

As  with  any  new  technical  product,  the  standards  are  continually  being  defined, 
making  it  difficult  for  published  requirements  to  keep  pace  with  changing  definitions 
(Masincup  and  others,  1996:632).  Some  problems  areas  identified  by  industry  and 
military  are  related  to  obsolete  standards  and  lack  of  standards.  Here  are  some  examples 
how  military  and  industry  see  the  problems  areas  in  the  IETM  development  environment. 
As  also  discussed  in  “graphics”  section,  Jorgensen  identifies  the  inefficiency  of  IETM 
standards: 
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IETMs  deployed  today  use  various  types  of  graphic  formats  and  styles. 

Although  graphic  standards  have  been  specified  in  several  industry 
standards,  including  CALS  and  the  Airline  Transportation  Association 
(AT A)  2100  most  IETMs  don't  use  or  support  these  standard  graphic 
formats.  As  a  result  of  the  ineffectiveness  of  the  CALS  standards  current 
IETMs  within  CALS  programs  usually  use  other  graphic  standards  or  no 
standards  at  all.  (Harvey,  1998) 

The  largest  customer  (DoD)  for  IETM  development  projects  are  not  without 

problems.  Jorgensen  identifies  problems  in  DoD  as  follows: 

As  the  use  of  IETMs  became  more  widespread,  it  became  important  to 
establish  an  infrastructure  to  manage  and  distribute  IETM  updates  to 
multiple  field  sites  and  to  provide  life-cycle  support  for  numerous  IETMs. 

In  this  environment,  the  fact  that  differing  IETMs  cannot  interoperate  (i.e., 
cannot  be  viewed  on  the  same  standard  presentation  system,  or 
electronically  reference  each  other  to  any  meaningful  level  of  internal 
granularity)  has  become  a  major  impediment.  (Jorgensen,  1998) 

There  are  some  concepts  to  encounter  the  challenges  in  today’s  IETM 

development  environment.  Two  of  these  concepts  are  Interoperability,  and  STEP. 

Interoperability  is  mostly  emphasized  in  military,  whereas  STEP  is  more  general  concept. 

STEP  concept  is  discussed  below;  interoperability  concept  is  left  for  a  further  research 

though. 


The  Standard  for  Exchange  of  Product  Model  Data  (STEP! 

Today,  product  design  and  product  documentation  are  totally  separated  processes 
and  there  is  practically  no  automated  information  flow  between  these  two  domains.  The 
integration  of  the  data  associated  with  a  product  and  its  documentation  is  a  primary  step 
toward  the  enterprise-wide  information  systems  that  are  needed  by  industry  today 
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(Electronic  Commerce  Connection,  Inc.  Web  page,  1998).  Product  data  and  product 
documentation  terms  are  defined  as  (Electronic  Commerce  Connection,  Inc.  Web  Page, 
1998): 

Product  data  carries  essential  information  about  the  design,  manufacture, 
operations,  etc.  of  the  actual  production  of  an  enterprise.  Most  product  data  is  created  and 
used  early  in  the  life  cycle  of  a  product  such  as  the  phases  of  design,  analysis,  and 
manufacturing. 

Product  documentation  describes  many  aspects  of  a  product:  its  design,  use, 
maintenance,  disposal,  etc.  Most  product  documentation,  for  example  training, 
maintenance,  and  operation  manuals  are  created  in  the  later  phases  of  a  product's  life 
cycle.  Product  documentation  uses  product  data  as  the  primary  source  of  information. 

Mr.  Holloway,  the  Air  Force  representative  in  Tri-service  ITEM  working  group, 
agrees  that  ITEMs  are  used  in  supporting  maintenance  and  training,  whereas  STEP 
concept  compromises  of  design,  manufacturing,  maintenance  and  support,  and  training 
for  a  given  product  (Holloway,  1998). 

The  combining  of  product  documentation  into  the  total  life  cycle  of  manufactured 
products  allows  more  effective,  timely,  and  accurate  descriptions  of  the  product  and  is 
profitably  reflected  in  many  parts  of  a  product's  life-cycle  (Electronic  Commerce 
Connection,  Inc  Web  Page,  1998). 

STEP  is  an  ISO  standard  (ISO  10303)  whose  goal  is  to  enable  a  product 
representation  to  be  exchanged  without  any  loss  of  completeness  (Commerce  At  Light 
Speed  (CALS)  Web  Page,  1998).  The  STEP/SGML  initiative  will  provide  a  mechanism 
for  information  objects  coming  from  the  STEP  environment  to  be  used  within  all 


45 


technical  manuals.  Creation  of  the  information  object  early  in  the  design  manufacturing 
process  will  ensure  that  the  information  is  correct  from  a  design  and  engineering 
standpoint.  The  information  objects  can  be  used  within  paper  manuals,  IETMs, 
Computer  Based  Training,  etc.  (Harvey,  1 998). 
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III.  Methodology 


Introduction 

The  case  study  of  Intercept  project,  between  O’Neil  &  Associates  and  Cummins 
Engine,  was  undertaken  to  investigate  IETM  development  process  in  a  civilian 
environment.  IETM  development  process  steps,  management  issues  that  contributed  to 
the  project’s  success,  and  different  implementation  issues  that  made  Intercept  project 
different  from  general  applications  are  discussed. 

This  chapter  details  the  research  design  employed,  methods  used  to  gather  data 
and  problems  to  be  possibly  countered  in  finding  answers  to  research  questions  posed  in 
Chapter  I.  Different  Knowledge  Acquisition  (KA)  techniques,  KA  problem  areas  and  the 
unstructured  interview  technique  are  discussed. 

Research  Design 

Developments  in  computer  and  electronic  technology  in  last  two  decades  made 
the  use  of  digital  data  available  and  preferable.  First  initiatives  to  utilize  digital  data 
came  from  military.  Although,  much  has  been  written  about  IETM  development  and  its 
advantages  in  military  sector,  little  research  has  been  done  in  civilian  environment, 
especially,  in  the  area  of  IETM  development. 

Since  this  study  emphasizes  what  IETM  development  process  steps  are,  how  the 
work  is  done  in  each  step,  why  some  alternative  methods  and  techniques  preferred  over 
others  in  Intercept  project,  the  case  research  method  is  the  best  research  method  for  this 
undertake.  Yin  summarizes  relevant  situations  for  different  designs  (Yin,  1994:6). 
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Table  1.  What  Questions  are  Relevant  for  Each  Research  Strategy?  (Yin,  1994:6) 


Strategy 

Form  of 
research 
question 

Requires  control 
over  behavioral 
events? 

Focuses  on 

contemporary 

events? 

Experiment 

How,  why 

Yes 

Yes 

Survey 

Who,  what,  where, 
how  many,  how 
much 

No 

Yes 

Archival  analysis 

Who,  what,  where, 
how  many,  how 
much 

No 

Yes/No 

History 

How,  why 

No 

No 

Case  study 

How,  why 

No 

Yes 

The  case  study  research  design  is  chosen  as  best  suited  for  this  effort.  Leenders 
and  Erskine  express  the  need  for  new  case  studies: 

“New  problem  areas,  new  theories  and  new  subject  approaches  need  to  be 
exposed”  (Leenders  and  Erskine,  1989:2). 

Yin  emphasizes  the  importance  of  case  studies: 

“The  case  study  allows  an  investigation  to  retain  the  holistic  and  meaningful 
characteristics  of  real-life  events”  (Yin,  1994:2). 

He  believes  that  the  following  areas  given  below  are  well  suited  for  case  study. 
(Yin,  1994:2). 

1 .  individual,  organizational,  social,  and  political  phenomena 

2.  psychology,  sociology,  political  science,  and  economics 

3.  organizational  and  managerial  processes 

4.  international  relations  and  maturation  of  industries. 
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The  researchers  believed  that  the  research  effort  undertaken  is  well  corresponded 
with  organizational  and  managerial  processes  for  the  purpose  of  this  case  study. 

Unit  of  Analysis 

Unit  of  analysis  refers  to  the  problem  of  defining  what  the  “case”  is.  A  case  may 
person,  a  group  of  people,  an  event  or  entity  (Yin,  1994:20-21).  In  this  study,  the  case  is 
Intercept  project  between  O’Neil  &  Associates,  IETM  developer,  and  its  customer, 
Cummins  Engine.  The  study  intends  to  expose  IETM  development  process  in  Intercept 
project,  and  to  include  situational  factors  such  as  the  level  of  relationship  between 
customer  and  contractor,  that  affected  the  project  success. 

Knowledge  Acquisition 

The  process  of  eliciting  knowledge  from  experts  in  field  to  support  decision 
support  systems  is  called  Knowledge  Acquisition.  Knowledge  Acquisition  activities  can 
be  divided  into  five  steps  (Byrd  and  others,  1992:1 19).  First  step,  identification  step,  is 
the  establishment  of  communication  between  the  Knowledge  Engineer  (KE)  and  the 
expert.  In  second  step,  conceptualization,  KE  interprets  data  to  draw  conclusions  about 
the  underlying  knowledge  of  the  expert.  In  third  step,  formalization,  KE  establishes  a 
model  that  represents  the  expert  knowledge  and  processes  by  using  his  or  her  knowledge. 
Fourth  and  fifth  steps  are  implementation  and  testing,  respectively,  but  these  two  steps 
are  not  valid  for  the  purpose  of  this  study  since  the  study  is  not  intended  to  directly  use 
acquired  data  in  field. 

Before  starting  a  new  project  in  business  or  in  private  life,  it  is  important  to  know 
problems  and  risks  that  are  likely  to  occur  in  project  life  cycle.  Knowing  them  will 
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increase  the  understanding  of  environment  and  probability  of  success.  Communication 
obstacles  that  affect  success  of  a  Knowledge  Acquisition  as  well  as  Requirement  analysis 
studies  are  divided  into  three  categories  (Byrd  and  others,  1992:122-123):  WITHIN, 
BETWEEN,  AMONG  obstacles. 

WITHIN  obstacles  are  the  results  of  cognitive  limitations  of  human  being.  As, 
human  beings,  experts  as  well  as  knowledge  engineers  are  limited  in  understanding 
natural  phenomena  and  in  processing  information  due  to  cognitive  shortcomings. 

BETWEEN  obstacles  are  results  of  cognitive  shortcomings  with  the  expert  and 
the  Knowledge  Engineer,  and  lack  of  common  language  between  them.  Experts  and 
knowledge  engineer  are  with  different  backgrounds  and  with  different  mind  set  (Byrd  and 
others,  1992:122). 

Although  above  two  obstacles  types  are  minimized  as  much  as  possible,  there  is 
one  more  obstacle  type,  namely,  AMONG  obstacles,  that  should  be  taken  into 
consideration  by  the  analyst.  AMONG  obstacles  are  associated  with  the  determination  of 
information  needs  of  users.  Increasing  number  of  users  means  increasing  number  of 
different  data  needs  that  should  be  balanced  in  the  study  by  analyst. 

Data  Collection 

In  case  studies  data  may  come  from  different  sources.  Yin  summarizes  these 
sources  in  six  categories,  three  of  which  were  used  in  this  study.  These  are,  namely, 
interviews,  participant-observations,  and  documentation  (Yin,  1994:  79). 

O’Neil  &  Associates  was  contacted  through  Tom  Milligan,  the  head  of  the 
marketing  department.  O’Neil  &  Associates  has  been  developing  different  types  of 
technical  manuals  since  1947.  After  the  company  informed  its  willingness  to  cooperate, 
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a  document  that  explained  the  purpose  of  the  study  as  well  as  the  research  questions  and 
expected  details  thereof  were  submitted  to  the  company.  Research  questions  developed 
by  researchers  can  be  categorized  into  two  categories.  First  category  questions 
emphasize  general  applications  in  IETM  development  process  for  different  situations, 
whereas  second  category  questions  emphasize  issues  that  are  specific  to  Intercept  project, 
on  which  the  case  is  based.  These  research  questions  are  given  at  Appendix  D. 

This  document  was  important  in  getting  the  permission  of  Cummins  Engine 
because  of  concerns  about  revealing  of  confidential  information.  After  the  approval  from 
Cummins  Engine  as  well  as  O’Neil  &  Associates,  the  researchers  made  weekly 
interviews  with  O’Neil  &  Associates.  Interview  schedule  emphasized  management  issues 
up-front,  and  process  issues  in  the  logical  order  later.  However,  interview  schedule 
affected  by  the  companies’  schedule  as  well  as  individuals’  availability. 

In  this  study,  open  interviews  were  employed  as  the  main  Knowledge  Acquisition 
technique.  The  greatest  advantage  of  interviews  lies  in  the  depth  and  detail  of 
information  that  can  be  secured  (Cooper  and  Emory,  1995:271).  They  provide  relaxed 
environment,  in  which  analyst  may  control  the  proceeding  of  Knowledge  Acquisition  by 
probing  with  additional  questions  and  by  adjusting  the  language  of  the  interview.  It  will 
increase  the  quality  of  the  data  gathered.  As  a  result,  they  can  help  move  aside 
BETWEEN  obstacles  (Byrd  and  others,  1992:130).  Interviews  questions  followed  from 
the  research  questions  were  developed  to  investigate  important  issues  mainly  in  two 
areas,  namely,  IETM  development  process  and  situational  realities  that  affected  the 
success  of  the  project. 
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Observation  and  documentation  were  the  other  sources  of  the  study.  When  the 
subject  under  discussion  were  hard  conceptualize,  the  researchers  requested  to  observe 
relevant  process  where  applicable.  Moreover,  the  final  product  and  its  functions  on 
Internet  browsers  were  also  observed.  O’Neil  &  Associates’  managers  provided 
documentation  about  the  previous  works  they  had  done,  about  the  processes  in  the 
company,  and  about  standardization  they  employed.  The  documentation  provided  helped 
to  understand  general  processes,  and  standards  employed,  thus  giving  chance  to 
researchers  to  compare  Intercept  project  to  other  projects. 

Summary 

The  methodology  used  in  this  study  is  mainly  qualitative  in  nature.  The  case 
study  design  is  used  to  gather  information.  The  primary  method  to  gather  data  is  the 
personnel  interviews  with  O'Neil  &  Associates’  personnel.  Knowledge  acquisition 
techniques  as  well  as  communication  obstacles  between  researchers  and  experts  are  also 
discussed  in  this  chapter.  Observation  and  documentation  provided  by 
0'Neil& Associates  are  the  other  sources  of  information  for  the  study. 

To  get  permission  of  O'Neil  &  Associates,  Inc.  to  make  the  case  study,  a 
document  was  prepared  that  explained  the  purpose  of  the  study  as  well  as  research 
questions  and  detail  thereof.  The  research  questions  on  this  document  axe  given  at 
Appendix  D.  The  following  chapter,  Chapter  IV,  discusses  the  case  itself. 
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IV.  Case  Study 


Introduction 

This  chapter  will  present  the  analysis  and  findings  of  the  research  effort.  As 
stated  in  prior  chapters,  the  purpose  of  this  thesis  was  to  conduct  a  case  study  on  the 
development  of  an  IETM  in  the  commercial  environment.  The  focus  of  this  chapter  will 
be  on  how  certain  steps  of  IETM  development  that  discussed  in  the  earlier  chapters  were 
implemented  in  this  specific  case,  what  factors  were  taken  into  consideration  in 
commercial  environment,  what  were  the  problem  areas,  and  how  they  were  handled. 

Background 

Over  a  number  of  years  Cummins  Engine  Company  has  produced  numerous 
engines  for  the  commercial  environment.  O’Neil  &  Associates,  Inc.  has  been  writing 
both  paper  manuals  and  IETMs  for  the  company  since  1996.  The  IETM  development 
project,  named  as  “Intercept”  by  O’Neil  &  Associates,  Inc.  is  the  development  of  a  CD- 
based  information  system  containing  20  different  types  of  manuals,  2000  interim  update 
documents,  Customer  Assistance  Center  Frequently  Asked  Questions,  and  the  customer’s 
Insite  Fault  Information  System.  The  CD  set  contains  more  than  1 5,000  pages  of 
technical  information,  including  Troubleshooting  &  Repair,  Operation  &  Maintenance, 
Warranty  Information,  and  any  interim  field  notifications,  which  may  impact  the  service 
history  of  a  database  of  more  than  250,000  engine  serial  numbers  (ESNs)  produced  by 
the  manufacturer.  More  than  16,000  illustrations  are  stored  in  a  graphics  database  as  GIF 
files  which  are  automatically  dropped  into  place  when  the  appropriate  file  is  displayed. 
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Key  product  features  include  documents  tied  to  engine  serial  numbers  or  configurations; 
information  based  on  the  users’  role  or  function  and  accessed  from  an  interactive  table  of 
contents;  improved  troubleshooting  navigation;  enhanced  procedural  text;  and  on-line 
help  and  user  manuals  with  printing  capabilities. 

Is  an  IETM  Really  Needed? 

The  decision  to  develop  an  IETM  was  made  by  the  Cummins  Engine  Company  as 
a  result  of  looking  for  a  way  to  improve  delivery  of  service  information  to  a  variety  of 
users.  Estimates  by  the  company  showed  that,  for  manuals  only,  annual  paper  output 
would  increase  from  18,000  pages  in  1996  to  28,000  pages  by  the  end  of  1997.  In 
addition,  Cummins  published  over  500  interim  documents  per  year  with  varying  levels  of 
distribution  and  security.  The  company  expected  to  make  the  information  more  timely, 
accurate,  and  accessible  by  using  electronic  format.  The  purpose  was  faster 
troubleshooting  and  quicker  repair  guides  in  a  much  smaller,  easier-to-use  package. 

In  spite  of  all  of  their  expected  benefits,  IETMs  have  been  proven  to  be  more 
costly  than  paper  manuals,  at  least  at  the  beginning  (Holloway,  1998;  Munguia,  1997). 
This  result  is  likely  to  be  caused  by  high  initial  costs  compared  to  low  life-cycle  costs. 
Main  cost  drivers  can  be  stated  as  the  cost  of  electronic  equipment  required  to  use  the 
IETM  at  the  beginning  and  the  cost  of  creating  digital  files.  This  cost  structure  does  not 
change  even  if  there  are  existing  paper  manuals  because  of  the  high  cost  of  the 
conversion  process  (Milligan,  1998).  In  addition,  these  manuals  require  a  complete 
change  not  only  in  manual  development  process  but  also  in  technical  procedures  such  as 
service,  maintenance,  trouble-shooting,  and  record  keeping.  As  a  result  of  these  facts, 
IETMs  are  mainly  preferred  by  big  companies  like  weapon  systems  or  airplane 
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manufacturers,  or  required  by  government  agencies  in  their  contracts.  In  most  of  the 
cases  either  the  agency  has  the  support  (or  requisition)  from  the  government  or  has  its 
own  service  web  and  a  huge  budget.  Being  in  a  pure  competitive  and  highly  customer 
oriented  environment,  primary  issues  that  Cummins  had  to  consider  before  beginning 
such  a  project  were  slightly  different  from  the  other  cases.  Number  one  driving  force  in 
identifying  the  scope  of  this  project  was  the  customer  response.  Customers  of  the 
company  at  26  different  countries  were  used  to  their  traditional  way  of  doing  job  for 
years.  This  fact  influenced  the  company’s  decision  to  continue  producing  and 
distributing  paper  manuals  and  presenting  IETM  as  an  additional  service.  The  wide 
range  of  customers  with  a  wide  range  of  technical  skills  and  capabilities  was  another 
problem  and  forced  both  parties  to  keep  the  requirements  as  simple  as  possible  at  the 
requirements  analysis  phase. 

Development  of  an  IETM 

As  a  data  sub-contractor,  O’Neil  &  Associates,  Inc.  is  implementing  a  program 
management  approach  in  its  contracts.  A  senior  specialist  within  the  organization  is 
appointed  to  organize  the  program  internally.  This  project  manager  assumes  full 
responsibility  for  quality,  technical  content,  schedule,  format,  and  customer  acceptance. 
The  general  method  of  operation  can  be  written  as  follows; 

1 .  Upon  award  of  a  contract,  a  meeting  between  Company’s  Program  Manager, 
applicable  project  managers,  and  the  customer  is  held  before  any  work 
commences.  In  this  way,  individuals  from  both  organizations  develop  a 
mutual  understanding  of  the  methods  and  the  practices  to  be  followed. 
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2.  The  managers  analyze  the  contract  requirements,  define  the  scope  of  each 
project,  plan  the  effort,  and  enter  the  man-hour  loadings  for  each  discipline 
and  the  critical  dates  for  each  task  into  the  company’s  computer  system. 

3.  Each  project  manager  reviews  the  available  source  material.  He/she  works 
with  the  customer  to  define  the  optimum  methods  of  collecting  and 
developing  the  other  necessary  information. 

4.  Writers  and  catalogers  study  the  source  data,  write  the  text,  and  define  the 
illustrations.  They  schedule  and  conduct  interviews  with  the  design 
engineering  staff  as  needed.  They  also  examine  and  operate  the  equipment  to 
ensure  that  the  procedures  are  correct  and  easy  to  follow. 

5.  As  the  program  develops,  in-process  reviews  with  the  customer  check  whether 
all  milestones  are  being  met  and  that  the  work  meets  the  customer’s 
requirements. 

6.  Official  validations,  conducted  by  writers  and  their  project  managers,  are  done 
to  provide  the  accuracy  and  usability  of  each  procedure. 

7.  Closely-managed  tracking  and  incorporating  of  engineering  changes  are  tried 
to  be  managed  to  ensure  that  all  publications  are  current. 

8.  After  pre-publication  review  by  the  customer,  final  products  are  produced. 

In  addition  to  this  general  approach,  IETM  development  requires  additional 

planning  and  additional  steps  depending  on  its  characteristics.  Prior  to  initiating  any 
consideration  of  an  IETM  project,  it  is  imperative  that  two  actions  be  completed:  1)  attain 
a  solid  functional  understanding  of  what  an  IETM  is,  and  2)  clearly  define  the  goals  and 
expectations  for  the  specific  application  (Masincup  and  others,  1996:632).  You  may 
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have  to  view  more  than  a  dozen  IETMs  before  these  items  are  solidly  in  your  grasp,  and, 
with  it,  a  solid  foundation  for  your  project.  In  addition,  a  process  for  the  development 
and  maintenance  of  the  IETM  must  be  clearly  defined  (Masincup  and  others,  1996:632). 
Basic  steps  implemented  by  O’Neil  &  Associates  in  this  IETM  development  process  are 
identified  as  follows: 

•  Preplanning 

•  Requirements  Analysis 

•  Document  Analysis 

•  DTD  Selection 

•  Project  Planning  and  Scheduling 

•  Conversion  Itself 

•  DTD  Conversion 

•  Hard  Copy  Conversion 

•  Electronic  Form  Conversion 

•  MS  Word 

•  Xyvision 

•  Graphics  Conversion 

•  SGML  Finalization 

•  Data  Enrichment 

•  Database  Management 

•  Production  Process 

•  Quality  Assurance 

•  Final  Product 
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The  characteristics  possible  for  an  IETM  application  are  limitless,  but  must  be 
defined  prior  to  beginning  the  development  process.  Items  which  must  be  defined  are: 

•  Goal  of  the  application  (instruction,  information,  reference,  or  a  combination). 

•  Level  of  interactivity  (text  links,  graphics  links,  level  of  user  response, 
situational  simulations,  etc.). 

•  User  controls  and  interface  (cuing,  “buttons”,  windows,  etc.). 

•  Simulations,  if  any  (animations,  video,  sound,  etc.). 

•  Graphics  (line  drawings,  color,  use  of  three-dimensional  models,  animations, 
video,  photographs,  etc.). 

•  Sound,  if  any. 

•  Hardware  limitations,  if  any  (will  existing  hardware  be  used  or  can  new 
hardware  be  defined?)  (Masincup  and  others,  1996:  633). 

All  of  these  items  must  be  identified  in  the  preplanning  step  and  mostly  in  the 
requirements  analysis  phase. 

Requirements  Analysis.  Various  classes  of  IETM  have  been  defined 
dependent  upon  their  interactive  functionality.  However,  these  classifications  should  not 
be  considered  as  constraints  on  a  development  process.  It  is  more  advantageous  to  begin 
by  defining  the  functions  needed  in  a  specific  IETM  and  tailoring  the  development 
process  to  the  need  rather  than  selecting  a  class  that  may  or  may  not  need  application 
needs  (Masincup  and  others,  1996:  632). 

The  requirements  analysis  step  implemented  in  this  project  can  be  divided  into 
two  parts,  which  mustn’t  be  an  extraordinary  application  in  competitive  commercial 


environment.  First  part  included  prioritizing  basic  product  functions  and  features  and 
was  done  by  different  entities  allowing  them  to  estimate  the  cost  of  the  project  and  make 
their  offer  to  the  company.  Second  part  completed  the  requirements  analysis  phase  in 
detail  and  was  done  by  the  contracting  (IETM  developer)  company  after  the  agreement 
was  reached  between  parties. 

First  Part:  Initial  Analysis  and  Offer.  First  part  of  the  analysis 
began  as  a  common  process.  The  customer  wanted  an  electronic  database  and  an 
interactive,  windows-like  format.  There  were  two  main  candidates  for  this  process. 
Robert  Heilman,  O’Neil’s  Director  of  Technical  Operations,  and  other  O’Neil  staff  met 
for  two  weeks  with  Kevin  Otto,  Director  of  Service  Publications  at  Cummins  Engine 
Company,  additional  Cummins  employees,  and  representatives  of  other  candidate 
IBM/ISSC  to  define  a  system  which  had  the  required  functionality.  The  group  suggested 
and  prioritized  product  functions  and  features  before  agreeing  on  a  set  of  criteria. 

System  requirements  were  identified  according  to  the  Cummins’  customer 
structure.  The  company  had  several  clients  that  were  not  electronically  advanced,  so  they 
wanted  a  system  with  minimum  requirements.  They  wanted  the  system  to  run  at  least  on 
386SX  type  personal  computers  with  Widows  3.1  operating  system.  This  was  the  first 
problem  for  the  O’Neil  &  Associates,  Inc.  because  O’Neil  was  using  Java  as  search 
engine  and  Windows  3.1  did  not  support  this  language.  Customer  also  wanted  the  output 
information  to  fit  any  kind  of  display  units  with  640*480,  800  *600,  or  1024  *  768 
resolution.  The  program  had  to  work  on  a  LAN  server,  Internet,  or  a  local  drive,  and  had 
to  be  accessible  by  most  common  browsers  Internet  Explorer™  and  Netscape 
Navigator™. 
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At  the  end  of  the  period,  the  group  agreed  on  a  set  of  criteria.  The  system  would 
show  a  number  of  manuals  and  interim  documents,  based  on  the  user’s  search  criteria, 
and  could  run  on  a  personal  computer  system  of  486DX  with  a  minimum  speed  of 
33MHz  and  8  megabytes  of  random  access  memory  (RAM)  using  Windows  3.1 
operating  system.  Users  would  navigate  the  software  with  buttons  which  emulated  those 
in  Windows  and  could  print  documents  using  the  browsers’  “Print”  function. 

IBM/ISSC  quoted  the  program  development  cost  at  $2million  for  two  years’ 
work.  Cummins  rejected  that  bid.  O’Neil  &  Associates  pledged  to  do  the  work  in  half 
the  time  at  half  the  cost.  Cummins  accepted  O’Neil’s  bid,  and  the  project  advanced  to  its 
second  step. 


Second  Part:  Detailed  Definition  of  Requirements.  There  are 
numerous  considerations  when  embarking  on  an  IETM  project,  and  little  written 
guidance  to  follow.  Some  of  the  items  that  are  highly  desirable  prerequisites  to  the 
initiation  of  IETM  development  can  be  stated  as  follows: 

•  The  technical  content  for  the  system  is  mature  and  well  documented  or  this  is 
a  new  system  where  all  material  will  be  prepared  from  the  onset  to  IETM 
requirements. 

•  The  IETM  developer  is  familiar  with  the  selected  IETM  software  and  end- 
user  target  audience. 

•  The  IETM  product  is  clearly  defined  based  on  customer  expectation  and 
concept  of  use  including  the  operating  platform  (hardware)  requirements. 

•  The  project  team  consists  of  individuals  experienced  with  IETM  design, 
development,  and  production. 
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•  The  customer  is  part  of  the  design  team. 

•  The  customer  has  objective  written  acceptance  criteria. 

•  The  quality  assurance  plan  and  organization  are  in  place. 

O’Neil  identifies  the  requirements  analysis  step  as  the  biggest  and  the  most 
important  part  of  the  project. 

...you  could  spend  a  month  doing  requirements  analysis  thinking  you  are 
going  to  do  it  this  way  and  then  you  will  come  across  something  that,  a 
piece  that  just  doesn’t  fit  and  you  will  have  to  back  all  the  way  out  almost 
to  the  beginning  and  then  take  off  in  another  direction.  So  requirements 
analysis  and  preplanning  phase  is  where  you  have  to  be  the  most  flexible 
and  it  takes  the  longest  time.  (Evans,  1998) 

The  company  tried  to  solve  this  problem  by  making  the  customer  a  part  of  the 
design  team  and  keeping  the  design  team  as  big  as  possible,  since  bringing  more  people 
together  would  bring  in  different  ideas  to  it.  First  meetings  of  the  team  were  held  as 
brainstorming  meetings.  Team  members  had  pieces  of  paper  and  wrote  down  one  of  their 
responsibilities,  and  continue  doing  that  until  they  had  written  everything  they  had 
thought  they  were  responsible  for  or  needed  to  do.  Then  they  took  those  pieces  of  paper 
and  placed  on  a  big,  poster  board,  where  they  thought  they  belonged  in  the  flow.  It  was 
amazing  for  the  team  members  to  see  the  amount  of  pieces  that  they  were  missing  in  the 
analysis.  Every  piece  of  paper  was  telling  what  should  have  been  completed  before  it  can 
begin  and  what  can’t  be  done  without  it.  After  every  piece  was  put  in  its  right  place,  the 
team  completed  its  flowchart.  The  second  part  was  identifying  the  responsibilities  each 
party  as  the  customer  and  the  contractor,  and  also  the  responsibilities  of  each  member  of 
the  team  individually. 
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Documents  Analysis.  Existing  paper  manuals  were  converted  to  an  IETM 


format  by  taking  the  original  text  and  electronic  files  and  tagging  them  using  Standard 
Generalized  Markup  Language  (SGML).  The  tagging  process  was  governed  by  a 
Document  Type  Definition  (DTD)  standard  that  defines  structure  for  every  SGML 
document  instance  in  the  IETM.  Second  step  was  converting  SGML  into  HTML  format 
that  can  be  viewed  by  required  browsers.  Following  steps  are  implemented  by  O’Neil  & 
Associates,  Inc.  to  analyze  the  structure  of  documents  to  be  converted  to  SGML: 

1 .  Analyze  several  documents  to  determine  the  type  of  manual  and  how  the 
major  sections  are  organized. 

2.  Analyze  the  document  structure  as  compared  to  the  DTD. 

3.  Analyze  the  anticipated  present  and  future  utility  of  the  SGML. 

4.  Establish  a  modularization  strategy  for  the  data. 

5.  Determine  the  enrichment  strategy. 

There  were  20  different  type  of  manuals  including  operation  and  maintenance, 
troubleshooting,  service  bulletins,  service  parts,  warranty  claims,  warranty  alerts,  and 
field  campaigns  to  be  put  in  the  IETM.  With  1,500  interim  documents,  term  used  by  the 
company  for  service  updates  sent  to  the  customer  before  the  new  manual  is  published, 
total  number  of  pages  to  be  converted  was  approximately  1 8,000.  Cummins  Engine 
Company  was  requiring  SGML  also  in  the  paper  manual  publishing  contracts,  so  most 
manuals  were  authored  in  SGML,  but  several  older  manuals  were  not  available  in 
electronic  format.  Interim  documents  were  written  in  Microsoft  Word.  Cummins  Engine 
Company  was  using  Xyvision  in  its  publishing  processes,  so  there  were  also  a  lot  of 
documents  in  this  format.  E-mail  system  of  the  company  was  containing  similar  text- 
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based  files.  Overall,  approximately  60  percent  of  total  documents  was  in  SGML  and  40 
percent  was  in  different  electronic  formats  and  paper. 

One  of  the  biggest  problems  at  that  point  was  to  tie  together  all  different  types  of 
information.  Engine  Groups  and  Engine  Serial  Numbers  (ESN)  were  the  most  suitable 
tying  factors  since  most  of  the  documents  had  something  to  do  with  an  engine  family. 

But  there  were  still  a  lot  of  data  that  can  be  related  to  the  same  number  and  a  lot  of  data 
that  can  be  left  outside.  As  a  solution,  some  numeric  codes  called  “meta-data”  added  to 
documents  to  provide  “hooks”  for  the  search  engine  to  sort  information  by  engine  family, 
build  year,  application,  or  fuel  system.  The  smallest  pieces  of  information  was  coded 
with  a  twelve  digit  number  identifying  engine  family,  group  code  (fuel  system, 
lubrication  system,  etc.),  procedure  code  (alternators,  etc.),  built  date,  and  application 
(remove,  install,  etc.).  Related  information  would  be  identified  and  pulled  by  query 
tables  created  in  the  database.  One  area  of  research  was  the  format  of  the  CD  itself  based 
on  the  ISO  9660  regulations.  The  ISO  9660  format  is  a  standard  for  cross-platform  CD- 
ROMs.  Discs  created  in  this  format  can  be  read  by  many  different  operating  systems, 
including  Mac,  DOS,  UNIX,  etc.  One  of  the  requirement  for  IETMs  was  to  be  operable 
on  Win  3.1  operating  system.  The  ISO  9660  level  that  supports  the  discs  intended  for 
DOS  or  Windows  3.x  systems  requires  use  of  file  names  to  be,  at  maximum,  8.3 
characters  length.  It  has  also  a  limitation  of  8  levels  of  nested  directories.  The  naming 
convention  and  directory  structure  were  defined  under  the  considerations  of  these 
constraints. 

Initially,  Intercept  was  to  contain  one  CD.  However,  development  team  decided 
to  have  separate  CDs  for  the  mid-range  engines  and  the  heavy-duty  engines  to  allow  for 
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inclusion  of  additional  manuals  in  the  future.  Some  of  the  interim  documents  were 
related  with  more  than  one  engine  family  so  they  were  included  on  both  CDs. 

At  that  point  it  may  be  useful  to  clarify  an  issue.  SGML  is  not  an  obligatory  step 
before  converting  text  files  into  browser- viewable  format.  Documents  can  be  converted 
directly  to  the  HTML  (Evans,  1998).  But  in  a  long-range  project,  SGML  allows  users  to 
view  or  access  their  information  in  different  forms  (Milligan,  1998).  Using  open  system 
approach,  SGML  encode  the  logical  structure  of  objects  below  the  document  level:  the 
various  levels  of  headings,  lists,  and  so  forth  that  people  pay  attention  to  when  actually 
reading  the  information.  Furthermore,  SGML  encodes  this  information  in  a  neutral 
format,  keeping  logical  content  separate  from  specific  layout  decisions,  and  allowing 
flexible  interchange  across  different  platforms  and  applications  (Severson,  1998). 
Keeping  their  database  in  SGML  allowed  Cummins  Engine  Company  to  publish  paper 
manuals  and  IETMs  at  the  same  time  while  all  the  data  is  coming  from  one  source  and 
provided  flexibility  in  possible  future  applications. 

DTD  Selection.  The  important  thing  to  understand  about  SGML 
applications  is  that  they  are  not  all  the  same.  There’s  actually  no  such  thing  as 
“converting  to  SGML,”  only  converting  to  a  specific  SGML  application.  SGML  is  not  a 
set  of  tags,  nor  even  a  specific  way  of  looking  at  your  information,  but  rather  a  language 
for  defining  the  way  you  want  to  look  at  your  information  (Severson,  1998).  “So  it  is 
really  nothing  to  SGML.  It  is  what  other  programs  do  with  it  that  turns  it  into 
something.”(Evans,  1998). 

SGML  applications  are  based  on  a  specific  DTD.  SGML  DTDs  catalog  the 
information  objects  (“elements”)  of  interest,  including  their  names  (“generic  identifiers”), 
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properties  (“attributes”),  and  allowed  content  (“content  models”).  Through  the  content 
models,  the  DTD  specifies  all  the  allowed  relationships  between  elements,  including 
hierarchical  document  structure,  specific  order  in  which  elements  must  appear,  how  many 
each  element  can  appear,  what’s  required  vs.  optional,  and  the  possible  links  between  the 
elements.  In  some  cases  current  DTD  may  support  another  application  or  require  small 
modifications.  Although  most  of  the  documents  to  be  converted  in  Intercept  project  was 
in  SGML  format,  current  DTD  was  strictly  for  paper  publishing  and  did  not  support 
required  application.  A  new  DTD  was  developed  to  allow  for  database  association, 
expert  level  summary  data,  role-based  filtering,  and  security  concerns.  New  DTD  was 
more  powerful  covering  additional  features  so  that  the  company  could  do  the  electronic 
version  and  the  paper  version  at  the  same  time.  Considerations  included  converting 
existing  SGML  files  to  the  new  DTD,  converting  non-SGML  legacy  data  to  the  new 
DTD,  and  converting  all  information  to  HTML  for  the  final  product. 

Project  Planning  and  Scheduling 

After  deciding  on  the  format,  next  step  was  establishing  a  master  schedule  of 
conversion  efforts  and  monitor  the  progress  against  that  schedule.  In  addition  to  this 
document,  O’Neil  &  Associates,  Inc.  prepared  a  data  dictionary  to  ensure  proper 
implementation  of  DTD.  Control  in  the  process  and  SGML  database  was  accomplished 
via  a  combination  of  automated  tools  and  process  oriented  inputs.  An  important  problem 
at  the  beginning  was  that  paper  publishing  and  authoring  process  was  continuing  at  the 
same  time.  Twenty  authors  were  writing  technical  information  for  the  manuals 
continuously.  The  team  studied  procedures  to  solve  this  problem  and  developed  a  master 
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schedule  plan,  which  showed  the  engine  families  and  the  number  of  pages  of  related 
information,  what  kind  of  procedures  they  have  to  take,  and  scheduled  completion  dates. 

Conversion  Process 

The  initial  conversion  was  accomplished  in  three  phases: 

1 .  Information  currently  in  SGML  was  converted  from  the  old  DTD  to  the  new 
DTD  format  using  both  automated  conversion  tools  and  manual  labor. 

2.  Non-SGML  information  was  converted  to  SGML  format  using  the  same 
procedure  but  requiring  more  labor. 

3.  Graphics  files  were  converted  from  TIF  to  GIF  files  and  checked  for  clarity 
and  accuracy. 

When  choosing  automated  conversion  tools,  differences  between  software 
packages  are  important.  Most  real-world  applications  demand  use  of  software  based  on 
software  recognition  rather  than  standard  “code-for-code”  translation  techniques.  The 
translation  approach  is  generally  inadequate  because  it  depends  on  absolute  consistency 
at  a  detailed  code  level.  “For  example,  consider  a  word-processor  document  containing 
section  headings  that  are  bold  and  centered.  A  typical  translation  rule  would  look  for  a 
“bold”  code  followed  by  a  “center”  code  as  the  indicator  that  a  heading  tag  should  be 
generated.  In  the  real  world,  of  course,  the  “center”  code  might  be  entered  first.  That 
calls  for  a  second  translation  rule.  But  what  if  the  centering  was  done  with  tabs,  or  the 
space  bar,  or  some  combination  of  both?  What  if  no  “bold”  code  is  present  because  bold 
had  already  been  turned  on  from  the  previous  object?”  (Severson,  1998).  Visual 
recognition  on  the  other  hand  looks  at  the  documents  the  way  people  do.  This  technique 
analyzes  the  net  effect  of  underlying  codes,  discovers  the  visual  objects  that  would  “meet 
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the  eye,”  and  assigns  them  names  based  on  user-defined  rules.  O’Neil  &  Associates,  Inc. 
used  a  combination  of  manual  and  software-assisted  conversion  in  Intercept  project. 
OmniMark™  is  used  as  the  automated  conversion  software. 

DTD  Conversion.  The  problem  of  converting  the  whole  existing  database 
from  old  DTD  to  the  new  one  was  solved  with  one-time-conversion.  There  were  separate 
databases  at  both  parties.  Cummins  Engine  Company  was  using  PDM  (Parlance 
Document  Manager)  as  a  database  management  tool.  PDM  was  a  shared,  interconnected 
database  and  allowed  multiple  users  to  use  and  change  the  data  simultaneously.  O’Neil 
&  Associates,  Inc.’s  database  system  consisted  of  VSS  (Visual  Safe  Source)  as  a 
repository  database  and  Texcel  as  the  management  tool.  In  order  to  be  able  to  convert  all 
the  database  to  the  new  format,  developers  stopped  all  the  authoring  processes,  migrated 
the  files  from  PDM,  and  stored  them  in  VSS.  The  authoring  process  stopped  during  the 
migration  and  did  not  begin  until  the  conversion  was  done.  Old  format  converted  into 
new  DTD  by  the  programmers,  and  the  files  were  put  back  in  the  database.  Once  this 
initial  conversion  accomplished,  there  was  no  further  need  for  conversion  in  SGML 
database  because  the  authors  would  continue  writing  in  the  new  format. 

Hard  Copy  Conversion.  The  first  step  in  converting  hardcopy  to  SGML  is 
getting  the  text  into  digital  form.  This  can  be  done  by  manual  rekeying,  or  automated  by 
OCR  scanning.  Either  way,  the  result  is  generally  an  ASCII  file  containing  text  and 
white  space.  With  hardcopy  documents,  all  structure  is  visual.  There  is  no  underlying 
encoding  to  translate  to  SGML.  OCR  (Optical  Character  Recognition)  software  packages 
convert  scanned  image  to  editable  text,  suitable  into  a  word  processor.  OCR  identifies 
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possible  errors  and  highlights  them.  For  example,  OCR  may  not  able  to  distinguish 
between  number  “l”and  letter  “1”,  or  number  “0”  and  letter  “O”.  The  operator  manually 
fixes  these  kinds  of  errors.  Today’s  OCR  packages  give  more  than  99  percent  success. 
But  OCR  errors  can  multiply  the  effect  of  errors  in  the  conversion  process.  Thus,  it  is 
usually  critical  to  clean  up  the  document  before  running  it  further  through  the  process. 
Still  scanning  and  OCR  along  with  corrections  saved  great  amount  of  time  for  O’Neil  & 
Associates,  Inc.  in  hard  copy  conversion.  O’Neil  personnel,  using  an  intelligent  scanning 
system,  scanned  printed  pages  and  stored  text  and  graphics  in  separate  files.  The  scanner 
that  is  used  in  the  process  was  able  to  process  pages  up  to  11”  x  17”  sheet  size  and  scan 
complex  page  layouts  having  multiple  text  columns  with  embedded  graphics  in  either 
portrait  landscape  mode.  The  software  could  process  the  text  from  either  single  or 
double-sided  originals. 

During  the  scanning  process,  text  and  graphics  are  scanned  simultaneously  and 
saved  as  separate  files.  The  scanning  system  included  a  conversion  module  that  can 
convert  the  text  to  more  than  50  word  processing,  desktop  publishing,  and  spreadsheet 
formats;  nine  raster  graphic  formats  were  also  available. 

Following  steps  are  used  to  convert  hard  copy  documents  to  SGML: 

1 .  Evaluate  the  quality  of  the  text  in  the  hard  copy  manual. 

2.  If  the  document  is  legible,  use  an  OCR  scanner  to  convert  the  text  to  Rich 
Text  Format  (RTF)  and  the  drawings  to  raster  graphics. 

3 .  If  the  document  is  not  legible,  use  a  word  processor  to  type  the  text  into  Word 
format  and  scan  the  graphics  as  raster  graphics.  Save  the  text  as  RTF. 
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4.  Using  OmniMark™,  develop  a  filter  that  will  convert  the  specified  RTF 
format  to  the  new  DTD.  A  separate  filter  must  be  developed  for  each  input 
hardcopy  format  and  for  each  output  DTD.  However,  many  documents  can  be 
processed  through  the  same  filter  as  long  as  the  input  and  output  formats  are 
consistent. 

5.  Using  the  OmniMark™  filter,  convert  the  digital  text  in  each  file  to  a 
preliminary  tagged  document.  If  the  input  file  format  or  the  DTD  output 
format  is  different  from  previous  jobs,  develop  a  new  filter  (step  2). 

6.  Go  to  finalization  process  to  populate  the  database,  parse  the  SGML  file, 
perform  the  quality  checks,  and  go  to  HTML  conversion  (see  Figure  9  below). 


Figure  9.  Hard  Copy  Conversion  (Adapted  from  O’Neil  &  Associates,  1997d) 
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Electronic  Form  Conversion.  Conversion  to  SGML  is  a  lot  easier  when 
input  has  been  authored  in  electronic  form.  However,  there  are  still  things  to  consider. 
The  input  must  be  in  a  format  the  conversion  software  can  automatically  read,  or  it  must 
be  easily  convertible  to  a  format  the  software  can  read.  Most  electronic  documents  in 
that  process  were  authored  with  only  paper  presentation  in  mind,  containing  no  more 
explicit  structure  than  scanned  hardcopy.  In  the  following  section,  several  processes 
identified  which  are  required  to  successfully  accomplish  the  conversion  effort.  The 
process  selected  is  dependent  upon  the  initial  media. 

MS  Word 


Figure  10.  MS  Word  Conversion  (Adapted  from  O’Neil  &  Associates,  1997d) 
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Following  steps  are  used  to  convert  Word  (any  version)  documents  to  SGML: 

1 .  Use  Word  to  open  the  file  that  is  to  be  converted. 

2.  Save  the  file  in  Rich  Text  Format  (RTF). 

3.  Using  OmniMark,  develop  a  filter  that  will  convert  the  specified  Word  (RTF) 
document  format  to  the  requisite  DTD.  A  separate  filter  must  be  developed 
for  each  input  Word  Format  and  for  each  out  put  DTD.  However,  many 
documents  can  be  processed  through  the  same  filter  as  long  as  the  input  and 
output  formats  are  consistent. 

4.  Using  the  OmniMark  filter,  convert  the  RTF  codes  in  each  file  to  a 
preliminary  tagged  document.  If  the  input  file  format  or  the  DTD  output 
format  is  different  from  previous  jobs,  develop  a  new  filter  (step  3). 

5.  Go  to  SGML  finalization  process  to  populate  the  database,  parse  the  SGML 
file,  perform  the  quality  checks,  and  go  to  HTML  conversion. 

Xwision  (XPP).  Similar  to  MS  Word  conversion, 
following  steps  are  followed  to  convert  Xyvision  (any  version)  documents  to  SGML: 

1 .  Retrieve  the  Xyvision  ASCII  file  that  is  to  be  converted 

2.  Using  OmniMark,  develop  a  filter  that  will  convert  the  specified  Xyvision 
ASCII  document  format  to  the  new  DTD.  Again,  a  separate  filter  must  be 
developed  for  each  input  Xyvision  format  and  for  each  output  DTD. 

3.  Using  the  OmniMark  filter,  convert  the  codes  in  each  file  to  a  preliminary 
tagged  document.  If  the  input  format  or  the  DTD  output  format  is  different 
from  previous  jobs,  develop  a  new  filter  (step  2). 
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4.  Go  to  SGML  finalization  process  to  populate  the  database,  parse  the  SGML 


file,  perform  the  quality  checks,  and  go  to  HTML  conversion. 
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Figure  11.  Xyvision  Conversion  (Adapted  from  O’Neil  &  Associates,  1997d) 
Graphic  Conversion.  Illustrations  from  the  legacy  shop  manuals  were 
existing  in  hard  copy  and  digital  format.  Regardless  of  the  graphic  format,  all  drawings 
must  have  been  converted  to  an  acceptable  form  that  can  be  viewed  by  the  browsers  at 
desired  quality.  Legacy  digital  graphic  files  in  Cummins  Engine  Company  database  were 
in  TIFF  format.  This  file  format  was  chosen  because  of  its  quality  in  paper  publishing, 
but  was  not  very  appropriate  for  electronic  display,  especially  because  of  the  space  it 
takes  in  the  memory.  TIFF  is  the  acronym  for  tagged  image  file  format,  one  of  the  most 
widely  supported  file  formats  for  storing  bit  map  images  on  personal  computers  (both 
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PCs  and  Macintosh  computer).  TIFF  graphics  can  be  any  resolution  and  they  can  be 
black  and  white,  gray-scaled,  or  colorful.  The  purpose  of  TIFF  is  to  describe  and  store 
raster  image  data. 

The  TIFF  files  were  converted  to  GIF  files  since  CD-ROM  was  based  on  Web 
based  technology  and  Web  base  can  not  handle  this  file  type.  Amount  of  space  they 
occupy  was  another  problem.  An  ordinary  TIFF  file  was  containing  3,000  pixels  and 
occupying  700-800  Kilobyte  space.  A  GIF  file  on  the  other  hand  was  visible  by  browsers 
and  occupying  approximately  15-20  Kilobyte  space  and  350-400  pixels.  GIF  is  a  bit¬ 
mapped  graphics  file  format  used  by  the  www  and  it  is  one  of  the  most  common  file 
formats  for  the  Internet.  It  has  the  smallest  file  size  for  graphics,  and  as  a  result  has  the 
fastest  download  speed.  Converting  graphics  into  GIF  decreased  the  resolution  of 
graphics.  However,  it  increased  the  download  speed,  and  helped  to  meet  the  requirement 
of  the  graphics’  fitting  different  computer  screens  with  different  resolutions.  After 
conversion,  GIF  files  were  checked  for  clarity  and  accuracy. 

Existing  files  were  converted  into  GIF  format  and  stored  in  the  database.  Hard 
copy  graphics  were  separated  from  text,  scanned,  and  stored  as  the  same  format.  There 
were  about  16,000  graphics  to  be  converted  in  total.  Following  procedures  were 
followed  in  graphics  conversion: 

1 .  If  there  are  no  digital  files  or  the  digital  files  are  not  acceptable,  scan  the 
printed  hard-copy  pages  to  create  GIF  graphic  files. 

2.  Examine  each  graphic  file  with  a  graphic  viewer.  Compare  the  image  on  the 
viewer  screen  with  the  image  as  it  appears  on  the  IETM  screen. 


73 


3.  Using  the  graphic  viewer,  examine  the  header  data  for  each  file.  Verify  that 
the  header  data  is  consistent  with  the  SGML-tagged  text  and  the  electronic 
manual.  It  is  very  important  to  compare  each  graphic  file  and  its  header  data 
against  the  SGML-tagged  text.  This  will  keep  graphics  from  being  assigned 
to  the  wrong  location  in  the  text. 

4.  Verify  that  the  SGML  <graphic>  and  <sheet>  tags  refer  to  the  correct  graphic 
file  names. 


Figure  12.  Graphic  Conversion  (Adapted  from  O’Neil  &  Associates,  1997d) 


74 


5.  Create  a  declaration  file  for  each  graphic.  Verify  that  the  data  in  the 
declaration  files  is  correct  (see  also  Figure  12  above). 

SGML  Finalization.  Final  step  in  SGML  conversion  process  included 
SGML  Parsing  and  several  quality  control  procedures.  The  purpose  of  the  SGML  parser 
is  to  recognize  markup  in  SGML  documents.  Together  with  the  entity  manager  (the 
software  component  that  makes  it  possible  to  segment  SGML  documents  into  separate 
entities),  it  forms  the  basis  of  any  conforming  SGML  system.  An  SGML  parser  does  not 
have  to  be  able  to  detect  errors;  the  only  requirement  of  an  SGML  parser  is  the  ability  to 
correctly  process  an  error-free  SGML  document.  The  parser  used  in  Intercept  is  called  a 
validating  SGML  parser  and  was  capable  of  finding  and  reporting  “reportable  markup 
errors”.  It  was  also  capable  of  optionally  reporting  other  errors  and  warning  of 
conditions  that  are  potential  causes  of  errors. 

Following  steps  are  followed  in  SGML  finalization  process: 

1 .  Transfer  the  tagged  files  to  a  document-control  database. 

2.  Use  an  SGML  editor  to  cleanup  the  text  using  one  of  the  following  steps  in 
accordance  with  project  requirements: 

a)  Format  Edit:  link  graphics,  verify  cross-references,  insert  missing 
entities,  correct  syntax  errors,  adjust  table  spans,  etc. 

b)  Content  Edit:  reorganize  text,  reposition  graphics,  update  the  technical 
content,  compensate  for  variations  in  source  material,  add  content 
level  tags  and  attributes,  etc.  That  process  had  to  be  performed  by 
technical  writers  who  are  familiar  with  the  subject  matter. 
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3.  Check  the  tagged  document  with  an  SGML  parser.  If  the  SGML  parser 
identifies  errors,  correct  the  errors  accordingly  (stepl). 

4.  When  the  document  parses  cleanly,  check  it  for  spelling  errors,  SGML  logic 
errors,  and  text  conversion  errors.  Correct  any  errors  accordingly  (stepl). 

5.  Go  to  HTML  conversion  process. 


Figure  13.  SGML  Finalization  (Adapted  from  O’Neil  &  Associates,  1997d) 
Data  Enrichment 


Besides  converting  existing  data,  IETM  developers  enriched  the  documents  with 
additional  information  such  as  meta-data,  summary  data,  warnings  and  cautions,  and 
cross  references.  Meta-data  was  added  to  documents  to  provide  “hooks”  for  the  search 
engine  to  sort  information  by  engine  serial  number,  family,  application,  build  year,  or 
fuel  system.  Summary  data  was  added,  allowing  users  to  either  see  procedure  highlights 
and  specifications  or  go  to  detailed  steps.  SGML  affectivity  tags  marked  information 
specific  to  certain  manuals  since  initial  information  was  stored  in  one  database  (single- 
source-authoring).  Referenced  procedures  were  hyperlinked,  allowing  users  to  quickly 
access  related  information  contained  either  in  another  section  of  the  manual  or  in  a 
separate  manual.  Troubleshooting  trees  were  grouped  by  problem  category  and  linked  to 
Cummins’  electronic  Insite  Fault  Information  System  by  adding  fault  codes  to  trees. 
Summary  data  was  provided  by  the  following  processes: 


1 .  Request  and  receive  Engineer’s  Draft  of  Summary  Data. 

2.  Review  and  reauthor  Engineer’s  Draft  into  Writer’s  Draft  of  Summary  data. 
This  involves  bringing  the  information  into  the  proper  style  and  format 
presentation. 

3.  Submit  Writer’s  Draft  for  Engineering/upline  review. 

4.  Make  corrections  as  required. 

5.  Ongoing  documentation  and  refinement  of  process. 

Total  data  enrichment  task  was  comprised  of  the  following  elements: 

1 .  Add  finalized/approved  Summary  Data  information  to  SGML  database. 

2.  Add  ID  to  Warnings  and  Cautions. 

3.  Hotlink  cross  references  as  required. 

4.  Other  data  enrichment  as  required. 

5.  Ongoing  documentation  and  refinement  of  process. 

Database  Management 

SGML  allows  the  identification  of  a  document  (paragraphs,  chapters,  titles, 
graphics,  etc)  as  discreet,  pre-defined  data  objects.  Since  SGML  presents  information  in 
a  highly  structure  form,  data  could  be  stored  and  maintained  in  a  database.  Storing 
information  in  database  allows  documents  to  be  linked  (connected  in  a  data  structure  by 
using  indexed  variables  or  pointers).  This  enables  documents  to  share  common 
information.  Not  only  does  this  save  writing  time  and  disk  space,  but  also  improves  the 
quality  and  accuracy  of  the  documents  and  ultimately  reduce  costs. 

After  the  conversion,  all  SGML  files  were  stored  in  a  modular  database  (PDM), 
which  was  physically  located  in  Cummins  Engine  Company  information  system.  SGML 
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database  enabled  Cummins  Engine  to  manage  information  as  objects  in  a  common 
database,  share  and  reuse  these  objects  in  multiple  documents,  and  publish  the  same 
information  in  multiple  formats.  Database  management  allowed  O’Neil  &  Associates, 
Inc.  to  actuate  paper  publishing  and  CD-ROM  publishing  simultaneously,  which  was  one 
of  the  most  important  requirements  for  the  project. 

In  PDM,  lowest  maintenance  level  information  was  described  as  modules  (data 
objects).  This  modular  concept  is  the  main  idea  behind  the  concept  of  developing 
information  once  and  using  it  many  times  in  different  places.  Suppose  an  alternator, 
which  is  used  in  different  engines.  Instead  of  authoring  the  information  several  times  in 
everywhere  needed,  the  author  can  write  data  once,  and  use  it  many  times  by  just 
pointing  to  that  one  module. 

The  naming  convention  for  data  modules  consisted  of  five  levels  for  Intercept 
project.  This  can  be  explained  by  the  following  example: 

035-002-136-020-002 

First  three  digits  (first  level)  gives  an  information  about  an  engine  family,  e.g. 

Ml  1  engine.  Second  three  digits  (second  level)  gives  an  information  about  the  group 
member  of  that  engine  family.  Cummins  technical  manuals  were  organized  under 
twenty-two  chapters,  each  chapter  for  a  major  component  of  an  engine.  Third  level  gives 
information  about  a  procedure,  e.g.  lubricating  the  oil  filter.  Fourth  level  gives 
information  about  the  step,  e.g.  install,  or  remove.  The  fifth  level  identifies  tasks  which 
differentiate  among  steps  for  different  situations. 

Since  project  consisted  of  large  amount  of  documentation,  there  was  redundant 
information  throughout  the  different  documents.  For  example,  some  warnings,  cautions, 
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and  illustrations  had  to  be  duplicated  many  times  throughout  a  manual.  In  a  conventional 
publishing  system,  creating  this  same  information  over  and  over  again  would  be  costly 
and  time  consuming.  When  changes  were  made,  the  writer  had  to  make  sure  that  each 
occurrence  is  properly  updated.  Repeating  the  same  information  at  different  locations  in 
a  document  would  increase  the  opportunity  for  error  and  likelihood  for  differences 
between  the  various  occurrences.  With  SGML  database,  each  of  these  common  entities 
appeared  just  once.  The  documents  required  only  a  pointer  (a  link)  in  each  place  the 
entity  required.  Since  the  entity  (warning,  caution,  drawing,  etc.)  had  only  one  physical 
location,  it  was  much  easier  to  maintain. 

SGML  database  gives  data  management  opportunities.  When  a  change  is  going 
to  be  made  on  existing  modules,  a  database  manager  assigns  that  particular  change  to  an 
author.  The  author  takes  a  copy  of  that  file  and  moves  it  onto  his/her  desktop.  He  or  she 
then  opens  up  the  file  in  ADEPT*Editor  (an  SGML  editor)  and  makes  the  necessary 
changes,  and  then  saves  it  and  posts  it  back  into  database.  During  that  time,  nobody  can 
work  on  that  module  and  make  changes.  This  application  forces  having  only  one  version 
for  each  document  every  time.  So,  anybody  who  uses  modules  from  the  database  knows 
that  it  is  the  last  versions  of  the  document.  The  database  allows  database  managers  to  see 
which  author  is  working  on  which  module.  This  makes  the  planning  of  activities  easier 
for  the  database  manager.  I  n  addition  to  database  managers  in  Cummins,  some  managers 
from  O'Neil  have  access  to  the  database  with  the  rights  of  a  database  manager. 

As  the  conversion  of  graphics  follows  different  but  parallel  workflow  to  text 
conversion,  the  storage  of  the  graphics  is  not  related  to  the  storage  of  SGML  data.  They 
still  reside  in  same  database  but  not  as  a  part  of  SGML  data.  Any  kind  of  graphics  can  be 
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used  and  recognized  by  SGML.  Inside  DTD,  the  engineer  tells  what  kind  of  graphic  files 
are  going  to  be  used  in  that  application.  The  only  thing  that  limits  the  use  of  any  graphic 
files  is  the  kind  of  medium  that  SGML  application  is  going  to  be  printed.  Overall,  SGML 
data  have  pointers  to  graphics.  When  a  graphic  file  is  needed  in  the  presentation  of 
SGML  data,  the  pointer  calls  for  that  particular  graphics. 

Production  Process 

Production  process  included  converting  SGML  database  into  HTML,  adding 
search  engine,  and  writing  on  the  CD’s.  Same  automated  conversion  tool  (OmniMark™) 
was  used  for  HTML  conversion.  Converting  SGML  files  into  HTML  format  is  also 
called  down  translation,  because  it  covers  all  transformations  of  a  “reference”  SGML 
document  base  into  derive  formats.  The  term  “down”  come  from  the  idea  that  the  SGML 
document  base  is  designed  to  model  the  suitable  level  of  information  for  the  project,  and 
as  a  result  corresponds  to  the  highest  level  of  information.  Going  from  this  level  of 
information  to  any  other  structure  is  therefore  a  down  translation.  Down  translation  can 
be  defined  and  formally  specified  as  a  structure-to-structure  mapping,  because  the  source 
of  the  transformation  is  a  formal  (SGML)  structure.  Thus,  HTML  conversion  process 
was  fairly  stable  and  reliable  process. 

Installation  program  and  search  engine  were  subcontracted  by  O’Neil. 

Developers  used  InstallShield™  software  for  ease  of  installation  and  to  build  in  security 
measures.  Users  recorded  a  serial  number  and  password  when  initially  installing  the  CD, 
regardless  of  whether  they  loaded  the  program  on  a  local  CD  drive,  local  area  network, 
local  web  server  placed  on  the  LAN,  or  remote  web  server  (intranet). 
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A  search  engine  was  created  using  Java  programming  language  to  link  engine 
serial  numbers  and  configurations  to  appropriate  manuals  and  interim  documents. 
Combined  with  a  C++  database  server,  the  interface  launched  and  controlled  the  Internet 
browser,  initiated  database  queries,  and  constructed  and  displayed  a  dynamic  table  of 
contents  listing  all  pertinent  documents.  Specifying  an  ESN  allowed  the  user  to  see 
information  specific  to  that  engine,  including  where  and  when  the  engine  was  built. 
Because  Windows  3.1  did  not  support  Java,  HTML  menus  were  included  with  hyperlinks 
for  navigation;  however,  no  ESN  searches  could  be  conducted. 

Quality  Assurance 

Both  Cummins  and  O'Neil  participated  in  quality  control  and  testing.  After 
developing  a  comprehensive  test  plan,  the  teams  used  automated  and  manual  methods. 
Quality  assurance  started  with  checking  the  electronic  files  for  consistency  and 
completeness.  These  files  were  compared  to  the  hard-copy  documents  that  they  were 
identical.  During  file  transfers  it  was  possible  that  data  may  be  added,  lost,  or  transferred 
incorrectly.  Catching  problems  early  during  the  project  helped  the  project  team  to  avoid 
the  problems  in  production  process.  After  each  document  was  converted  into  SGML, 
tagged  data  was  compared  to  original  documents.  That  was  a  two-fold  process.  First,  the 
documents  were  compared  to  ensure  that  no  data  was  lost  during  the  conversion 
procedure.  Second,  the  tags  were  checked  for  accuracy.  An  SGML  parser  was  used  to 
check  the  tagging  completeness,  however  a  parser  could  not  catch  everything.  Team 
members  found  that  combining  manual  proof-reading  with  electronic  checking  using 
multiple  parsers  gave  the  best  results  to  ensure  the  quality  of  process.  The  functionality 
and  contents  of  the  CDs  were  verified.  In  addition,  Cummins  arranged  applications  for 
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field  testing  and  receiving  of  customers’  feedback.  The  software  tested  on  various 
hardware  configurations,  using  Windows  3.1,  Windows  95,  and  Windows  NT  operating 
systems  and  both  browsers. 

Final  Product 

The  first  CD  for  the  heavy-duty  engines  was  released  in  November  1997,  and  the 
mid-range  CD  was  released  in  March  1998.  The  CD  set  contains  more  than  20  manuals, 
1,500  interim  documents,  18,000  pages  of  technical  information,  and  16,000  illustrations 
as  well  as  Customer  Assistance  Center  Frequently  Asked  Questions  and  Cummins 
Engine  Company’s  Insite  Fault  Information  System.  Using  a  search  routine  based  on 
ESN,  engine  type,  or  fuel  system,  an  engine  specific  Table  of  Contents  is  created  on-the- 
fly  to  allow  access  to  information  tailored  to  the  user  in  a  “role  based  view”  (Field 
Technician,  Warranty  Administrator,  etc.).  When  accessing  the  repair  and  maintenance 
procedures,  the  user  can  scroll  through  a  detailed  task  description  complete  with  support 
illustrations;  or  in  the  case  of  a  more  experienced  user,  can  complete  the  task  by  means  of 
summarized  version  of  the  procedure.  Procedural  data  and  troubleshooting  are 
interactively  linked  to  other  manuals,  and  to  the  Fault  Information  System  for  online 
trouble  shooting  and  diagnostic  support.  Users  subscribed  to  the  service  and  received 
updates  every  two  months.  According  to  Cummins  Engine  Company  customer  feedback, 
Intercept  covered  a  large  percentage  of  data  frequently  used  by  a  broad  range  of  target 
users.  Future  plans  of  the  company  includes  adding  hyperlinks  to  service  tool 
instructions,  an  on-line  parts  list  manual  application,  warranty  coverages  by  engine  serial 
numbers,  and  new  manuals.  Longer-term  upgrades  may  include  additional  markets  and 
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information  types,  integration  with  other  products  and  systems,  full  text  search  capability, 
updated  interim  documents  via  internet  and  e-mail,  and  forums/chat  services. 
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V.  Conclusions.  Recommendations,  and 
Suggestions  for  Future  Research 


Introduction 

This  chapter  will  summarize  the  research  effort  and  offer  conclusions  to  the 
research  based  on  the  findings  presented  in  Chapter  IV.  It  includes  a  lessons  learned  part 
which  summarizes  what  was  learned  about  IETM  development  process  at  the  end  of  this 
case.  Recommendations  concerning  future  Air  Force  training  and  suggestions  for  future 
research  will  also  be  presented. 

Lessons  Learned 

In  any  IETM  development,  the  “starting  point”  and  “ending  point”  are  critical 
factors  for  determining  the  nature  of  the  project.  By  “starting  point”,  we  mean  the 
technical  information  itself,  and  its  format.  Technical  information  may  be  in  variety  of 
formats  such  as  on  paper,  in  electronic  form,  or  in  SGML.  The  accuracy  of  technical 
information,  and  consistency  of  its  structure  are  the  determinants  of  the  difficulty  of 
conversion.  Suppose,  there  are  two  types  of  document  in  electronic  format  such  as  a 
word  document.  Suppose,  furthermore,  one  of  them  has  very  consistent  structure, 
whereas  the  other  has  a  loose  structure.  An  automated  conversion  can  be  validated  for 
the  technical  information  with  consistent  structure,  whereas  a  loose  structured  document 
may  have  to  be  reauthored  in  SGML. 

By  “ending  point”,  we  mean  interactivity,  hardware,  and  software  requirements. 
Interactivity  requirements  determine  how  an  IETM  will  interact  with  users.  IETMs  may 
require  simply  linear  representation  of  technical  information  when  interactivity  is 
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minimum.  On  the  other  hand,  they  may  help  the  technician  with  the  task  he  or  she  is 
doing  where  interactivity  is  high,  such  as  fault  identification,  or  trouble  shooting  with  the 
help  of  artificial  intelligence.  The  main  difference  between  a  paper  manual  and  an  IETM 
is  that  IETMs  are  enriched  by  hypertext  and  hypermedia.  You  can  enrich  technical  data 
in  a  variety  of  ways  such  as  by  adding  pop-up  menus,  audio  files,  and  video  files.  You 
can  add  data  base  hooks  to  other  related  information  such  as  other  databases,  and 
complementary  information  (warranty,  and  service  information  etc.).  Hypertext  and 
hypermedia  information  which  may  be  explicit  or  implicit  in  technical  data  must  be 
captured  in  document  analysis. 

Hardware  and  software  requirements  also  have  important  implications  on  how 
IETMs  are  developed.  Naming  convention  in  Intercept  had  be  restricted  8.3  length 
according  to  ISO  9660  standard  since  it  was  requirement  that  IETMs  would  be  operable 
on  Win  3.1  operating  system.  Remember,  new  versions  of  two  browsers,  namely, 
Internet  Explorer,  and  Netscape  Navigator  did  not  allow  the  use  of  developed  Intercept 
IETMs.  However,  users  did  not  have  problems  since  old  versions  were  supplied  in 
Intercept  CDs.  Another  considerations  in  Intercept  were  fitting  all  graphics  into  variety 
of  screens  with  different  resolutions.  That  challenge  was  handled  by  modifying  graphics 
by  percentages  in  GIF  format.  These  are  examples  from  Intercept  project  that  point  out 
the  importance  of  hardware,  and  software  implications  on  an  IETM  development  project. 

In  above  discussion,  it  emphasizes  the  important  implications  of  “starting  point” 
and  “ending  point”  by  examples  in  any  IETM  development  project.  Preplanning  is  the 
stage  where  all  these  issues  as  well  as  other  related  issues  are  solved.  Early  decisions 
made  in  the  project  determine  the  success  of  an  IETM  development  project.  They  are 
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vital  since  it  may  prove  to  be  costly  to  alter  them  in  later  stages.  Activities  in  preplanning 
can  be  grouped  under  several  categories  as  we  did  in  Chapter  IV.  “Proof  of  concept”  is 
the  stage  where  IETM  development  project  is  shown  to  be  possible  and  affordable. 
“Identification  of  system  requirements”  is  the  stage  where  output  specifications  and 
functionality  requirements  (these  are  called  and  “ending  point”  above  in  this  discussion) 
are  identified  in  the  areas  of  interactivity,  hardware,  and  software  requirements. 
“Document  analysis”  is  the  stage  where  input  documents  are  analyzed  (identification  of 
“starting  point”).  The  most  important  output  of  preplanning  process  is  the  mapping  of 
IETM  development  activities  from  “starting  point”  to  the  ending  point.  It  requires 
identification  of  responsibilities  of  the  IETM  developer  company  and  its  customer  in 
project  level;  responsibilities  of  each  person  in  development  level;  consistent  flowchart 
for  activities;  and  selection  of  right  hardware  and  software  tools.  It  is  important  to  require 
the  participation  of  people  from  each  profession  such  as  authoring,  programming,  and 
manufacturing  since  acquiring  inputs  from  different  disciplines  helps  to  early 
identifications  of  inefficiencies  in  planning. 

After  the  discussion  of  importance  of  preplanning  activities  in  addition  to 
implications  of  “starting  point”  and  “ending  point”  for  the  success  of  an  IETM 
development  project,  the  conversion  process  itself  is  going  to  be  discussed  now.  The 
common  thing  about  all  input  documents  is  that  they  are  all  converted  into  SGML  format. 
This  is  called  “up  translation”,  as  discussed  in  Chapter  II.  “Up”  follows  from  the  fact  that 
SGML  is  highest  level  of  markup  languages  that  all  other  languages  can  be  defined  from 
it. 
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Before  going  further  with  the  discussion  of  conversion  issues,  we  want  to  point 
out  SGML  is  not  the  only  IETM  solution.  For  example,  Portable  Document  File  (PDF)  is 
another  format  that  is  encountered  in  IETM  projects.  As  discussed  in  chapter  2,  PDF  is  a 
de  facto  standard  in  IETM  industry.  For  example,  U.S.  Air  Force  has  chosen  to  convert 
the  16  million  page  legacy  data  (existing  TOs)  to  Indexed  Portable  Document  Format  in 
April  1995.  Almost  half  of  the  customers  of  O'Neil  has  been  demanding  their  IETMs  in 
PDF  format,  SGML  is  increasingly  gaining  popularity  among  its  customers  at  the  time  of 
this  thesis.  We  think  the  main  consideration  behind  these  facts  is  the  conversion  cost  of 
legacy  data.  As  one  of  O'Neil  &  Associates  personnel  points  out,  you  can  get  cost 
savings  as  much  as  one  to  ten  by  selecting  PDF  rather  than  SGML  as  your  IETM  format. 
You  can  mix  PDF  applications  with  SGML.  However,  the  major  drawback  with  PDF  is 
that  it  is  not  easy  to  make  changes  in  PDF  applications.  For  example,  you  can  change  or 
add  one  sentence,  but  you  can  not  add  one  paragraph  to  a  page.  You  have  to  redo  IETM 
development  for  considerable  changes  with  PDF. 

It  is  possible  to  categorize  input  documents  for  “up-translation”  into  three 
categories:  1)  hardcopy,  which  is  thought  to  be  the  hardest  starting  point  of  all  three, 

2)  electronic  documents,  which  comprise  of  large  variety  of  documents  other  than 
hardcopy,  and  3)  SGML,  which  is  thought  to  be  the  easiest  starting  point  among  all  three. 
It  is  important  to  point  out  that  electronic  formats  are  elusive.  The  conversion  of  them 
may  be  as  hard  as  hardcopy  in  situations  where  structure  of  documents  is  considerably 
inconsistent,  and/or  accuracy  of  technical  information  is  low.  On  the  other  hand,  when 
the  structure  is  very  consistent  such  as  with  most  technical  documents  developed  in 
markup  languages,  you  may  expect  successful  automated  conversion.  However,  in  most 
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of  electronic  conversion  projects,  human  review  is  still  required  for  quality  control 
purposes.  Hardcopy  conversion  requires  scanning  activity  to  convert  technical 
information  to  electronic  format,  then  to  SGML.  Scanning  is,  further,  going  to  be 
discussed  later  in  this  chapter. 

As  discussed  in  Chapter  II,  “down-translation”  is  the  conversion  from  SGML  to 
other  formats  such  as  to  HTML  format  for  Web  publishing.  Another  approach  is  SGML- 
aware  software.  For  example,  Magliery  says  one  alternative  to  converting  SGML  to 
HTML  is  developing  SGML-aware  software  that  can  browse  the  Web,  either  by  itself  or 
with  help  of  another  browser  (Magliery,  1998).  There  are  some  companies  such  as 
Softquad-the  Panorama  viewer,  and  Hal-the  OLIAS  browser,  which  are  developing  this 
approach.  However,  it  seems  that  this  approach  has  not  been  proven  to  be  cost-effective 
for  end  users  in  the  field  yet,  as  of  today.  Overall,  SGML  can  be  published  on  Web,  on  a 
CD,  on  paper,  or  other  formats.  “Down-translation”  is  generally  easier  than  “up- 
translation”  since  information  is  at  the  highest  level  in  SGML  format. 

Last  two  topics  that  are  going  to  discussed  under  this  section  are  Quality 
Control/Quality  Assurance  and  SGML  database  management.  The  quality  assurance 
program  and  the  quality  control  itself  are  the  insurance  that  all,  but  right  technical 
information  is  captured,  and  tagging  is  complete  and  consistent.  A  good  planning  at  early 
stages  is  key  to  success.  Some  of  activities  can  be  automated  such  as  using  parsers  to 
check  the  tagged  instance  conforms  the  rules  defined  by  respective  DTD.  However  the 
importance  of  human  review  in  the  process  is  vital  for  success.  The  best  way  to  approach 
quality  control  activities  is  to  use  automated  tools  and  human  review  together,  as 
complement  to  each  other. 
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As  discussed  earlier,  SGML  is  just  ASCII  text.  What  makes  SGML  applications 
so  attractive  is  what  other  tools  do  with  it.  A  database  is  one  of  these  tools.  An  SGML 
database  allows  the  management  of  technical  data  as  data  objects  (modules).  A  data 
object  is  the  smallest  bit  of  information  that  resides  in  database,  but  how  big  the  size  of 
these  objects  requires  a  decision  by  the  IETM  developer.  For  example,  in  the  Intercept 
project  an  install  or  a  replace  procedure  (called  step  by  project  team  as  discussed  in 
Chapter  IV)  was  a  data  object. 

The  importance  of  the  size  of  a  module  is  best  explained  by  an  example.  Suppose, 
a  maintenance  procedure  such  as  an  install  or  replace  procedure  with  a  part  number 
within  the  text  of  this  procedure.  You  may  call  the  maintenance  procedure  as  the 
smallest  data  object,  by  leaving  the  part  number  as  it  is  in  the  text.  Another  scenario  for 
this  example  may  be  identification  of  the  part  number  also  as  a  data  object.  This  very 
same  number  may  be  a  part,  say,  of  100  maintenance  procedures.  Defining  the  part 
number  as  data  object  gives  the  chance  of  making  an  update  about  the  part  number  once, 
and  using  it  many  at  different  places.  Because  the  part  number  exists  in  database  in  one 
place,  and  all  maintenance  procedure  that  have  this  part  number  as  part  of  their  text  point 
to  it.  This  approach  gives  better  management  of  data  since  you  make  capture  a  data  once, 
use  it  many  places.  However,  the  cost  is  another  consideration  in  making  a  decision 
about  how  much  modularity  you  want.  This  decision  should  follow  from  the  realities  of  a 
given  project.  Do  the  benefits  of  high  level  of  modularity  outweigh  the  costs  entailed? 
Above,  important  factors  that  have  implications  on  an  IETM  development  application  are 
discussed.  Now,  IETM  development  activities  are  going  to  be  visualized  as  a  process  in 
Figure  14.  As  can  be  noticed  from  the  Figure  14,  an  IETM  development  process  may 
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exactly  look  like  the  process  of  electronic  publishing  in  different  sectors  of  industry.  The 
reason  for  this  is  that  IETM  concept  is  a  result  of  technological  improvements  in 
computer  technology,  not  vice  versa.  However,  SGML  is  not  restricted  to  IETM  concept. 
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Figure  14.  IETM  Development  Activities 


Figure  14  emphasizes  IETM  development  as  a  process.  However,  one  important 
consideration  in  IETM  development  is  support  and  maintenance  of  IETMs.  This  may 
require  upgrading  of  software  and  hardware  requirements;  updating  the  content  of  IETMs 
itself.  One  other  point  that  should  be  emphasized  is  that  quality  control  seems  a  part  of 
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conversion  step  in  Figure  14.  The  reason  is  to  emphasize  quality  control  activities 
including  both  automated  and  manual  in  that  step.  However,  quality  control  and  quality 
assurance  (QC\QA)  program  comprises  all  IETM  development  steps.  It  requires 
contribution  of  both  developer  and  customer,  and  starts  as  early  as  in  preplanning  step. 

Conclusions 

Driving  Factors  of  Private  Sector 

Our  case  study  showed  that  prioritization  of  driving  forces  in  private  sector  is 
different  from  the  military  environment.  Let’s  look  at  what  DoD  expects  as  benefits  from 
IETM  implementation  (Pechersky,  1989:67): 

•  increase  in  productivity  by  automating  authoring  process. 

•  improvement  in  trouble-shooting  accuracy. 

•  Savings  in  technical  manual  reproduction,  acquisition,  and  system  life-cycle 
costs. 

As  can  be  seen,  most  of  the  driving  factors  that  DoD  takes  into  consideration  are 
related  with  technical  and  operational  improvement.  In  the  above  list  taken  from  a  report 
prepared  for  DoD,  cost  factor  comes  third,  and  customer  response  is  not  even  mentioned. 
This  is  usually  the  order  met  in  any  DoD  source.  In  private  sector,  on  the  other  hand,  we 
saw  that  there  are  two  main  drivers: 

1 .  Customer  response:  Unless  the  company  also  manipulates  maintenance 
actions  of  its  products  or  a  leader  in  the  industry,  developing  an  IETM  is 
strictly  dependent  upon  whether  its  customers  want  it  or  not. 
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2.  Cost:  If  the  overall  cost  along  with  cost  of  missed  sales  because  of  lack  of 
electronic  manuals  (if  any)  is  more  than  cost  of  current  applications,  it  is 
highly  difficult  for  a  firm  in  the  private  sector  to  justify  the  change  to  IETMs. 
Only  after  these  factors  are  met,  are  the  other  benefits  discussed  above  considered. 

Importance  of  Coordination  and  Using  Standards 

An  IETM  development  requires  the  collaboration  of  many  people  from  different 
disciplines  such  as  authoring,  programming,  and  manufacturing.  It  is  also  vital  that  both 
customer  and  developer  have  the  same  understanding  of  final  product.  In  Intercept 
project,  O'Neil  was  the  only  IETM  developer  company;  however,  there  may  be  situation 
in  which  an  IETM  development  is  a  group  effort  among  several  IETM  developers.  In 
this  case  coordination  of  activities  is  more  vital  for  the  success  of  the  project.  The  main 
contractor  bears  most  of  the  coordination  responsibility.  (Rest  of  this  discussion  mostly 
relates  a  new  development  from  scratch,  not  a  conversion).  First  of  all,  the  main 
contractor  should  specify  a  DTD.  It  is  also  important  that  it  specify  a  naming  convention 
for  common  technical  terms  so  that  everybody  can  use  same  names  when  referring  to 
same  tool,  or  same  procedure  etc.  Another  issue  is  the  use  of  the  same  orthographic  (flat) 
graphics  by  every  contractor.  The  main  contractor  should  come  up  with  orthographic 
graphics  for  common  items  such  as  screws,  bolts,  etc.  and  distribute  them  to 
subcontractors.  This  will  allow  consistent  graphic  representation  of  common  items  in 
different  graphics.  For  example,  a  screw  may  be  used  ,say,  fifteen  subcomponents  of  an 
engine.  Not  having  a  standard  representation  format  would  cause  different  representation 
of  the  same  screw  as  a  part  of  these  subcomponents.  In  international  projects,  one  issue 
to  above  discussion  should  be  added  the  use  of  simplified  English. 
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Dash  8  is  a  major  aircraft  program  O’Neil  &  Associates  is  part  of.  There  are 
fifteen  major  partners  that  are  responsible  for  different  aircraft  systems  (fuel,  hydraulics, 
power  plant,  etc.).  These  partners  are  located  all  around  the  world.  All  partners  are 
responsible  for  their  chapters  of  the  Aircraft  Maintenance  Manual  (AMM)  and  Illustrated 
Parts  Catalog  (IPC).  To  maintain  the  consistency  throughout  the  manuals,  the  Airframe 
Manufacturer  has  developed  extensive  and  detailed  specifications  for  SGML,  writing, 
and  illustrations.  Uniformity  is  also  accomplished  through  use  of  AECMA  (The 
European  Association  of  Aerospace  Industries)  Simplified  English.  (O'Neil  &  Associates, 
1996e). 

AECMA  Simplified  English  has  been  developed  by  the  aerospace  industry  and  its 
customers  to  help  the  preparation  of  maintenance  manuals  that  are  both  clear  and 
unambiguous  for  English  speakers  and  non-native  English  speakers  alike  (The  European 
Association  of  Aerospace  Industries  Web  Page,  1 998).  The  specification  provides  a  set 
of  writing  rules  and  a  dictionary  of  agreed  words  with  their  meanings. 

Above  example  illustrates  the  importance  of  the  use  of  standards  when  the  project 
requires  several  IETM  developers  either  in  national  level  or  international  level.  Another 
reason  for  using  standards  can  be  tied  to  technological  changes  in  processing  digital  data. 
Rapid  change  in  technology  requires  changes  in  companies’  service  and  maintenance 
strategy,  input  and  output  devices,  input  and  output  formats,  and  technical  requirements 
and  capabilities.  In  order  to  be  able  to  use  technical  data  that  has  been  produced  before, 
new  systems  can  be  capable  of  handling  legacy  data  or  data  that  has  been  produced  in 
different  platforms.  Only  in  that  case  can  major  objective  of  digitization  efforts  “creating 
data  once”,  and  “using  it  many  times  in  many  places”  be  achieved. 
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Role  of  the  DoD  in  Establishing  Standards 

During  the  case  study,  the  researchers  noted  that  when  there  is  a  lack  of  standards 
in  industry,  DoD  standards  are  either  directly  used  or  referenced  by  industry.  U.S. 
military  has  been  the  leading  player  in  IETM  standards  because  of  its  position  and  its 
relative  size.  Although  there  are  some  standardization  efforts  in  terms  of  development  of 
a  common  DTDs  for  specific  sectors  such  as  ATA  100,  ATA  21000,  and  ASE  J2008 
specifications,  these  efforts  are  not  as  big  as  those  undertaken  by  DoD.  Being  the  largest 
customer  makes  DoD  a  leader  in  establishing  standards  for  digital  data  applications. 

That  is  also  appropriate  for  the  industry  because  of  two  reasons: 

1 .  Industry  itself  is  in  search  of  global  standards. 

2.  U.S.  military  is  the  largest  contracting  agent  in  the  world.  Most  of  the  firms  in 
private  sector  are  doing  work  with  DoD  in  some  phase  of  their  company  lives 
and  have  to  comply  with  these  standards. 

Identifying  a  third  reason  as  “DoD  has  managed  to  establish  well  built  standards” 
is  out  of  scope  of  this  study.  But  it  is  a  reality  that  these  standards  are  not  sufficient  in 
today’s  environment.  Writers  of  this  thesis  do  not  expect  the  role  of  DoD  in  establishing 
standards  in  digitization  to  increase  in  the  near  future  because  of  the  other  more  powerful 
trends  in  defense  environment,  which  force  the  military  to  buy  whatever  is  available  in 
the  market  as  much  as  possible,  and  in  some  cases  avoid  highly  detailed  standard 
definitions. 

Role  of  Conversion  in  IETM  Development 

Another  finding  of  the  study  was  that  conversion  process  occupies  an  important 
place  in  today’s  IETM  development  efforts.  This  is  primarily  because  legacy  data  exists 
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in  different  forms.  Lack  of  standards  in  either  creating  digital  files  or  developing  IETMs 
makes  any  type  of  conversion  obligatory  at  some  place.  As  discussed  in  chapter  2, 
product  documentation  is  traditionally  considered  as  the  last  step  in  a  production  process 
in  the  life  cycle  of  a  product.  Unless  the  technical  data  that  is  created  in  the  earlier 
phases  of  the  life  cycle  of  a  product  does  support  the  product  documentation,  problem  of 
converting  from  one  type  to  another  is  likely  to  continue.  For  example,  the  graphics 
developed  in  the  research  and  development  with  CAD\CAM  tools  can  be  directly  used  in 
the  production  of  technical  documentation.  However,  this  was  not  the  case  in  new  IETM 
development  efforts  in  O'Neil  since  most  of  its  customer  could  not  supply  original 
engineering  drawings  developed  with  CAD\CAM  tools.  This  caused  the  duplication  of 
efforts  in  IETM  development  process.  The  engineers  who  develop  engineering  drawings 
were  hopeful  that  they  were  able  get  CAD\CAM  drawings  from  their  customers  in  the 
future,  thus  they  would  not  have  to  redevelop  them  later. 

Future  Considerations 

In  a  rapid  changing  environment  in  which  you  don’t  know  what  the  future  will 
require,  the  things  to  consider  before  beginning  an  IETM  development  project  are 
limitless.  Some  factors  to  consider  in  addition  to  technical  and  operational  aspects 
discussed  in  this  study  may  be  adjusting  the  product  according  to  the  developments  or 
changes  in  technology,  or  setting  standards  at  a  very  high  level  that  will  allow  the  product 
to  be  compatible  with  the  future  technologies.  Although  this  is  a  difficult  task,  it  is  not 
impossible  since  new  applications  are  not  completely  disregarding  the  old  technologies. 

It  is  debatable  that  these  factors  must  be  thought  by  the  customers  and  identified  in  the 
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agreement,  or  it  is  data  producer  companies’  task.  But  planning  about  future  gets  more 
important  in  an  IETM  development. 

Which  Class  of  IETM? 

In  intercept  project,  the  system  requirements  did  not  require  the  restructuring  of 
technical  data,  thus  IETMs  in  Intercept  could  be  thought  as  class  3  IETM  in  terms  of 
DoD  classifications.  However,  technical  data  is  managed  as  data  object  (modules)  in  an 
SGML  database.  And  this  is  the  one  of  the  requirements  for  class  4  in  DoD.  So,  is  it 
better  to  call  IETMs  in  Intercept  project  class  3  or  class  4  according  to  DoD 
classifications?  What  is  important  is  that  an  IETM  should  reflect  the  needs  of  user.  It  is 
important  to  start  with  users’  need,  and  prioritizing  them.  And,  your  requirements  should 
be  finalized  as  a  result  of  cost-benefit  analysis  during  preplanning  stage.  However,  it  is 
not  right  to  sacrifice  some  of  important  systems  requirements  due  to  cost  considerations. 
Converting  your  technical  documents  to  SGML  would  not  guarantee  adding  new  features 
in  a  cost-effective  way  in  the  future.  For  example,  converting  your  legacy  data  into  class 
3  IETM,  and  requesting  to  promote  it  class  4  in  future  may  prove  to  be  costly  since 
technical  information  has  to  be  restructured  hierarchically. 

Recommendations  for  Future  Research 

In  this  thesis,  an  IETM  development  project,  namely,  Intercept,  in  industry  setting 
is  investigated.  Important  factors  that  have  implications  on  IETMs  and  IETM 
development  steps  themselves  are  explained.  As  one  can  see  (See  Figure  14),  an  IETM 
development  as  a  process  is  not  very  different  from  an  electronic  publishing  project  in 
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industry.  It  becomes  clear  IETM  development  process  will  be  affected  by  changes  in 
technology  and  standards,  not  vice  versa. 

As  discussed  in  Chapter  II,  today’s  IETM  development  is  not  without  problems. 
One  of  the  problem  is  that  standards  can  not  keep  pace  with  technology.  IETMs  deployed 
today  use  various  types  of  graphic  formats  and  styles.  As  discussed  in  Chapter  II,  most 
IETMs  uses  proprietary  styles  since  SGML  does  not  support  styles  as  opposed  to  content, 
and  structure.  This  case  study  is  a  typical  example  of  the  ineffectiveness  of  graphics 
standards.  Deployed  IETMs  in  Intercept  project  were  in  GIF  format  to  support  Web 
browsers.  None  of  CALS  graphic  standards  support  Web  based  publishing  which  is 
becoming  very  popular  for  Internet  as  well  as  CD-ROM  publishing.  A  follow-on  study 
could  focus  on  possible  solutions  to  ineffectiveness  of  IETM  standards.  Particularly, 
what  type  of  solutions  can  be  expected  from  the  development  of  STEP  standards  which 
aim  to  combine  product  documentation  into  the  total  life  cycle  of  manufactured  products. 

Another  problem  area  in  today’s  IETM  development  environment  is 
interoperability.  It  is  more  emphasized  in  military  than  industry.  Jorgensen  identifies  the 
problem  as  follows: 

As  the  use  of  IETMs  became  more  widespread,  it  became  important  to 
establish  an  infrastructure  to  manage  and  distribute  IETM  updates  to 
multiple  field  sites  and  to  provide  life-cycle  support  for  numerous  IETMs. 

In  this  environment,  the  fact  that  differing  IETMs  cannot  interoperate  (i.e., 
cannot  be  viewed  on  the  same  standard  presentation  system,  or 
electronically  reference  each  other  to  any  meaningful  level  of  internal 
granularity)  has  become  a  major  impediment.  (Jorgensen,  1996) 

There  are  several  projects  in  DoD  to  provide  solutions  to  interoperability 

problems  with  IETMs.  The  interoperability  problem  and  possible  solutions  provided  by 

Interoperability  projects  in  DoD  can  be  an  area  of  a  research. 
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There  are  some  articles  in  literature  which  discuss  the  possibility  of  getting  rid  of 
technical  manuals.  As  discussed  in  Chapter  1 ,  technical  documentation  for 
technologically  advanced  system  is  increasing  exponentially.  Technical  procedures  as 
maintenance  and  operation  of  are  getting  more  and  more  complex.  Including  technical 
information  within  product  is  one  of  the  approaches  discussed  in  literature.  A  follow-on 
research  may  investigate  the  possibility  of  getting  rid  of  technical  manuals  in  the  future. 

Summary 

This  thesis  investigated  how  a  specific  IETM  development  application  is 
accomplished  in  a  civilian  environment.  First,  benefits  of  IETMs  and  problems  with 
paper  manuals  were  discussed.  Then,  IETM  development  steps  were  identified.  These 
steps  were  preplanning,  conversion,  database  management,  and  deployment.  The  specific 
case  example  involves  conversion  of  legacy  data.  The  form  of  this  legacy  data 
necessitated  conversion  to  SGML  (known  as  "up-translation"),  while  the  requirement  for 
usability  with  commercially  available  browsers  also  entailed  "down-translation"  to 
HTML.  Lessons  learned  from  the  case  study  were  also  discussed.  Among  them  was  the 
understanding  of  different  driving  factors  which  motivated  organizations  in  industry  than 
those  in  DoD.  The  customer  response  and  cost  were  main  considerations  for  industry  in 
an  IETM  development  project,  while  operational  and  technical  improvements  such  as 
enhanced  trouble  shooting  and  reduced  maintenance  time  were  emphasized  in  DoD. 
Overall  this  thesis  was  important  in  two  aspects: 

•  It  identified  IETM  development  steps,  about  which  there  was  little  research 
effort  in  the  literature. 
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It  investigated  a  specific  case  in  a  civilian  environment.  There  was  a  little 
research  about  what  civilian  industry  was  doing  about  IETMs,  especially  in 
the  area  of  how  IETMs  are  developed. 


Appendix  A.  Glossary  of  Terms 


ASCII  (American  Standard  Code  for  Information  Interchange-).  The  basis  of  character 
sets  used  in  almost  all  present-day  computers.  This  is  the  de  facto  worldwide  standard  for 
the  code  numbers  used  by  computers  to  represent  all  the  upper  and  lower-case  Latin 
letters,  numbers,  punctuation,  etc.  There  are  128  standard  ASCII  codes,  each  of  which 
can  be  represented  by  a  7  digit  binary  number:  0000000  through  1111111. 

ATA  100.  ATA  (Air  Transport  Association)  standard  that  specifies  document  type 
definition  to  be  used  in  by  the  airlines  and  related  manufacturers  at  development  of 
technical  manuals. 

ATA  2100.  ATA  (Air  Transport  Association)  standard  that  establishes  recommended 
standards  for  the  presentation  of  technical  information  prepared  as  digital  media 
(magnetic  tape  or  CD-ROM)  produced  by  aviation  manufacturers  and  used  by  airlines 
and  other  segments  of  the  industry  in  the  maintenance  of  their  respective  products  (Air 
Transport  Association  -Publications). 

Automated  Conversion  Tools.  Software  based  translation  techniques  used  to  translate 
one  type  of  file  format  into  another. 

Bitmap.  A  data  file  or  structure  which  corresponds  bit  for  bit  with  an  image  displayed  on 
a  screen,  probably  in  the  same  format  as  it  would  be  stored  in  the  display's  video  memory 
or  maybe  as  a  device  independent  bitmap.  A  bitmap  is  characterized  by  the  width  and 
height  of  the  image  in  pixels  and  the  number  of  bits  per  pixel  which  determines  the 
number  of  shades  of  gray  or  colors  it  can  represent. 

BLOB.  Binary  Large  Objects. 
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Browser.  A  client  program  (software)  that  is  used  to  look  at  various  kinds  of  Internet 


resources. 

CAD\CAM.  Computer  Aided  Design  \  Computer  Aided  Manufacturing. 

CALS.  Continuous  Acquisition  Life-cycle  Support.  A  DoD  and  industry  strategy  to 
enable  the  integration  of  digital  technical  information,  including  technical  manuals  (TOs), 
for  system  /  equipment  acquisition,  design,  manufacture,  and  support. 

CCITT  Group  4  (International  Consultative  Committee  on  Telegraphy  and  Telephony). 
CALS  standard  for  raster  graphics  incorporating  tiling,  which  divides  a  large  image  into 
tiles.  You  can  exchange  graphic  files  in  CCITT/4  format  in  a  compressed  state  so  they 
take  up  much  less  file  space. 

CD-ROM.  Compact  disk-read  only  memory 

CGM  (Computer  Graphics  Metafile).  One  of  the  CALS  standard  formats  for  representing 
2-D  technical  illustrations.  CGM  is  an  object-oriented  graphic  format. 

Client.  A  computer  system  or  process  that  requests  a  service  of  another  computer  system 
or  process  (a  "server")  using  some  kind  of  protocol  and  accepts  the  server's  responses. 

Cross-Translation.  Occurs  when  there  is  an  SGML  document  that  uses  DTD  “A”  and 
now  DTD  “B”  is  the  preferred  form. 

Database  Management  System.  A  suite  of  programs  which  typically  manage  large 
structured  sets  of  persistent  data,  offering  ad  hoc  query  facilities  to  many  users. 
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Descriptive  Markup  (also  known  as  “generic  markup”).  Describes  the  purpose  of  the  text 
in  a  document  rather  than  its  physical  appearance  on  the  page. 

Document  Instance.  SGML  tagged  document.  It  is  also  called  tagged  instance. 

Document  Type.  SGML  introduces  the  notion  of  a  document  type.  Documents  are 
regarded  as  having  types,  just  as  other  objects  processed  by  computers  do. 

Down-Translation.  Conversation  from  SGML  to  other  formats.  A  typical  example  of 
“down-translation”  is  the  conversion  of  data  from  SGML  format  into  HTML  format. 

DTD  (Document  Type  Definition).  Formal  definition  of  the  elements,  structures,  and 
rules  for  marking  up  a  given  type  of  SGML  document. 

DSSSL  (Document  Style  Semantics  and  Specification  Language).  An  international 
standard  that  applies  to  the  specification  of  processing  information  for  SGML  documents. 

Encoding.  Converting  data  or  some  physical  quantity  into  a  given  format. 

Ethernet.  A  very  common  method  of  networking  computers  in  a  LAN.  Ethernet  will 
handle  about  10,000,000  bits-per-second  and  can  be  used  with  almost  any  kind  of 
computer. 

FOSI  (Formatting  Output  Specification  Instance!.  A  DTD  standard  used  for  formatting 
SGML  documents  for  printing  and  other  outputs.  It  is  a  separate  file  that  contains 
formatting  information  for  each  element  in  a  document. 

GIF  (Graphic  Interchange  Format).  A  common  format  for  image  files,  especially  suitable 
for  images  containing  large  areas  of  the  same  color.  GIF  format  files  of  simple  images 
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are  often  smaller  than  the  same  file  would  be  if  stored  in  JPEG  format,  but  GIF  format 
does  not  store  photographic  images  as  well  as  JPEG. 

HTML  ('Hypertext  Markup  Language!  The  coding  language  used  to  create  Hypertext 
documents  for  use  on  the  World  Wide  Web.  HTML  looks  a  lot  like  old-fashioned 
typesetting  code,  where  you  surround  a  block  of  text  with  codes  that  indicate  how  it 
should  appear.  Additionally,  in  HTML  you  can  specify  that  a  block  of  text,  or  a  word,  is 
linked  to  another  file  on  the  Internet.  HTML  files  are  meant  to  be  viewed  using  a  World 
Wide  Web  Client  Program,  such  as  Netscape  or  Mosaic. 

Hypermedia.  All  kinds  of  sound  and  video  attachments  incorporated  into  electronic 
documents,  which  will  be  accessible  via  hyperlinks. 

Hypertext.  Any  text  that  contains  links  to  other  documents  -  words  or  phrases  in  the 
document  that  can  be  chosen  by  a  reader  and  which  cause  another  document  to  be 
retrieved  and  displayed.  A  link  doesn't  just  have  to  be  text,  however  —  pictures  and  icons 
can  also  be  "clickable." 

IETM  (Interactive  Electronic  Technical  Manuals').  A  package  of  information  required  for 
the  diagnosis  and  maintenance  of  a  weapon  systems,  optimally  arranged  and  formatted 
for  interactive  screen  presentation  to  the  end-user. 

IGES  (Initial  Graphics  Exchange  Specification).  Standard  for  exchanging  3-D  vector, 
CAD  type  data;  primarily  used  for  translating  engineering  drawings  into  digital  form. 

Internet  (Upper  case  IT  The  vast  collection  of  inter-connected  networks  that  all  use  the 
TCP/IP  protocols  and  that  evolved  from  the  ARPANET  of  the  late  60’s  and  early  70’s. 
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The  Internet  now  (July  1995)  connects  roughly  60,000  independent  networks  into  a  vast 
global  internet. 

internet  (Lower  case  i).  Any  time  you  connect  two  or  more  networks  together,  you  have 
an  internet  -  as  in  inter-national  or  inter-state. 

Intranet.  A  private  network  inside  a  company  or  organization  that  uses  the  same  kinds  of 
software  that  you  would  find  on  the  public  Internet,  but  that  is  only  for  internal  use. 

ISO  (International  Organization  for  Standardization).  An  industry-supported 
organization  that  establishes  worldwide  standards  for  everything  from  data  interchange 
formats  to  film  speed  specifications. 

JAVA.  A  simple,  object-oriented,  distributed,  interpreted,  robust,  secure,  architecture- 
neutral,  portable,  dynamic,  general-purpose  programming  language  developed  by  Sun 
Microsystems  in  1995.  Java  supports  programming  for  the  Internet  in  the  form  of 
platform-independent  Java  "applets". 

Knowledge  Acquisition.  Process  of  eliciting  knowledge  from  experts  in  field  to  support 
decision  support  systems. 

LAN  (Local  Area  Network).  A  computer  network  limited  to  the  immediate  area,  usually 
the  same  building  or  floor  of  a  building. 

Lexical  Analysis.  The  first  stage  of  processing  a  language.  The  stream  of  characters 
making  up  the  source  program  or  other  input  is  read  one  at  a  time  and  grouped  into 
lexemes  (or  "tokens")  -  word-like  pieces  such  as  keywords,  identifiers,  literals  and 
punctutation.  The  lexemes  are  then  passed  to  the  parser. 
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Lexical  Analyzer.  The  initial  input  stage  of  a  language  processor  (e.g.  a  compiler),  the 
part  that  performs  lexical  analysis. 

Markup.  In  computerised  document  preparation,  a  method  of  adding  information  to  the 
text  indicating  the  logical  components  of  a  document,  or  instructions  for  layout  of  the  text 
on  the  page  or  other  information  which  can  be  interpreted  by  some  automatic  system. 

Meta-data.  Data  about  data.  In  data  processing,  meta-data  is  definitional  data  that 
provides  information  about  or  documentation  of  other  data  managed  within  an  application 
or  environment.  For  example,  meta  data  would  document  data  about  data  elements  or 
attributes,  (name,  size,  data  type,  etc)  and  data  about  records  or  data  structures  (length, 
fields,  columns,  etc)  and  data  about  data  (where  it  is  located,  how  it  is  associated, 
ownership,  etc.).  Meta  data  may  include  descriptive  information  about  the  context, 
quality  and  condition,  or  characteristics  of  the  data. 

Network.  Hardware  and  software  data  communication  systems.  Any  time  you  connect 
two  or  more  computers  together  so  that  they  can  share  resources,  you  have  a  computer 
network.  Connect  two  or  more  networks  together  and  you  have  an  internet. 

MIL-HDBK-2800.  An  SMGL  implementation  guide  used  by  U.S.  military. 

MIL-PRF-87268.  A  military  IETM  specification  that  defines  how  the  IETM  should  look 
and  behave  to  the  reader. 

MIL-PRF-87269.  A  military  IETM  specification  that  establishes  the  IETM  database 
forms,  structure,  and  key  controlling  mechanisms. 

MIL-Q-87270.  A  military  IETM  specification  that  prescribes  the  requirements  for  an 
IETM  Contractor’s  Quality  Assurance  (QA)  program. 
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Object  Oriented  Programming.  Writing  programs  in  one  of  a  class  of  programming 
languages  and  techniques  based  on  the  concept  of  an  "object"  which  is  a  data  structure 
encapsulated  with  a  set  of  routines,  called  "methods"  which  operate  on  the  data. 
Operations  on  the  data  can  only  be  performed  via  these  methods,  which  are  common  to 
all  objects  which  are  instances  of  a  particular  "class". 

OCR  (Optical  Character  Recognition).  Process  of  turning  an  image  into  computer-edible 
format.  Recognition  of  printed  or  written  characters  by  computer. 

OmniMark™.  Automated  conversion  tool  that  is  used  in  Intercept  project  for  both  digital 
format-to-SGML  and  SGML-to-HTML  conversion. 

OS  (Output  Specification').  Standards-based  style  sheets  developed  by  DoD.  It  is  in  the 
form  of  a  particular  DTD  that  allows  the  user  to  create  a  Formatting  Output  Specification 
Instance,  or  FOSI. 

PDF  (Portable  Document  Format).  The  native  file  format  for  Adobe  Systems'  Acrobat. 
PDF  is  the  file  format  for  representing  documents  in  a  manner  that  is  independent  of  the 
original  application  software,  hardware,  and  operating  system  used  to  create  those 
documents.  A  PDF  file  can  describe  documents  containing  any  combination  of  text, 
graphics,  and  images  in  a  device-independent  and  resolution  independent  format.  These 
documents  can  be  one  page  or  thousands  of  pages,  very  simple  or  extremely  complex 
with  a  rich  use  of  fonts,  graphics,  colour  and  images. 

PPM  (Parlance  Document  Manager).  A  compound  document  management  system  that 
enables  users  to  manage  information  as  objects  in  a  common  database,  share  and  reuse 
these  objects  in  multiple  documents,  and  publish  the  same  information  in  multiple 
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formats.  In  this  case  it  is  used  by  Cummins  Engine  Company  as  a  database  management 
tool. 

Pixel.  Picture  element.  The  smallest  resolvable  rectangular  area  of  an  image,  either  on  a 
screen  or  stored  in  memory.  Each  pixel  in  a  monochrome  image  has  its  own  brightness, 
from  0  for  black  to  the  maximum  value  (e.g.  255  for  an  eight-bit  pixel)  for  white.  In  a 
color  image,  each  pixel  has  its  own  brightness  and  color,  usually  represented  as  a  triple  of 
red,  green  and  blue  intensities. 

Procedural  Markup.  Defines  what  processing  is  to  be  carried  out  at  particular  points  in  a 
document. 

Product  Data.  Carries  essential  information  about  the  design,  manufacture,  operations, 
etc.  of  the  actual  production  of  an  enterprise. 

Product  Documentation.  Describes  many  aspects  of  a  product;  its  design,  use, 
maintenance,  disposal,  etc. 

Proof  Concept.  Making  it  sure  that  the  data  conversion  for  legacy  information  is  both 
possible  and  affordable. 

RAM  (Random  Access  Memory).  A  data  storage  device  for  which  the  order  of  access  to 
different  locations  does  not  affect  the  speed  of  access. 

RTF.  Rich  Text  Format.  An  interchange  format  for  exchange  of  documents  between 
different  document  preparation  systems. 

OC\OA.  Quality  Control  \  Quality  Assurance. 
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Operating  System.  The  low-level  software  which  schedules  tasks,  allocates  storage, 
handles  the  interface  to  peripheral  hardware  and  presents  a  default  interface  to  the  user 
when  no  application  program  is  running. 

Raster  Images.  Computer  graphics  in  which  an  image  is  composed  of  an  array  of  pixels 
arranged  in  rows  and  columns.  They  are  presented  as  matrix,  or  grid,  or  tiny  black  and 
white  dots. 

SAE  J2008  t Society  of  Automotive  Engineers').  A  family  of  standards  developed  by  the 
membership  of  the  Society  of  Automotive  Engineers  to  provide  easy  access  to  emission- 
related  automotive  service  information. 

Search  Engine.  A  remotely  accessible  program  that  lets  you  do  keyword  searches  for 
information  on  the  Internet  or  other  browsable  documents.  There  are  several  types  of 
search  engines;  the  search  may  cover  titles  of  documents,  URLs,  headers,  or  the  full  text. 

SGML  (Standard  Generalized  Markup  Language).  An  international  standard  (ISO  8879), 
published  in  1986,  for  the  definition  of  device-independent,  system-independent  methods 
of  representing  texts  in  electronic  form. 

SGML  Parser.  An  algorithm  or  program  to  determine  the  syntactic  structure  of  a 
sentence  or  string  of  symbols  in  some  language,  in  this  case  SGML.  A  parser  normally 
takes  as  input  a  sequence  of  tokens  output  by  a  lexical  analyser.  It  may  produce  some 
kind  of  abstract  syntax  tree  as  output. 

SOL  (Structured  Query  Language).  De  facto  access  language  for  relational  databases. 
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STEP  (The  Standard  for  Exchange  of  Product  Model  Data).  ISO  standard  (ISO  10303) 
whose  goal  is  to  enable  a  product  representation  to  be  exchanged  without  any  loss  of 
completeness. 

Tag.  A  formatting  command  included  an  HTML  (or  other)  document.  In  the  world  of 
SGML,  a  tag  is  marker  embedded  in  a  document  that  indicates  the  purpose  or  function  of 
the  element.  Each  element  has  a  beginning  and  ending  tag. 

Tagged  Instance.  SGML  tagged  document.  It  is  also  called  document  instance. 

TCP/IP  (Transmission  Control  Protocol/Intemet  Protocol!.  This  is  the  suite  of  protocols 
that  defines  the  Internet.  Originally  designed  for  the  UNIX  operating  system,  TCP/IP 
software  is  now  available  for  every  major  kind  of  computer  operating  system.  To  be  truly 
on  the  Internet,  your  computer  must  have  TCP/IP  software. 

TeX.  A  typesetting  system  that  it  is  intended  for  the  creation  of  beautiful  books-and 
especially  for  books  that  contain  a  lot  of  mathematics. 

TIFF  (Tagged  Image  File  Format!.  A  file  format  used  for  still-image  bitmaps,  stored  in 
tagged  fields.  Application  programs  can  use  the  tags  to  accept  or  ignore  fields,  depending 
on  their  capabilities.  While  TIFF  was  designed  to  be  extensible,  it  lacked  a  core  of  useful 
functionality,  so  that  most  useful  functions  (e.g.  lossless  24-bit  color)  requires 
nonstandard,  often  redundant,  extensions.  The  incompatibility  of  extensions  has  led 
some  to  expand  "TIFF"  as  "Thousands  of  Incompatible  File  Formats". 

TO.  Technical  Order 
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Token.  A  basic,  grammatically  indivisible  unit  of  a  language  such  as  a  keyword,  operator 
or  identifier. 

Unix.  An  interactive  time-sharing  operating  system  invented  in  1969  by  Ken  Thompson. 

Up-translation.  Conversion  from  other  formats  to  SGML.  Since  SGML  is  thought  to  be 
highest  level  information,  this  conversion  process  is  called  “up-translation”. 

Vector  Images.  A  drawing  program  which  deals  with  separate  shapes  such  as  lines, 
polygons,  and  text  and  groups  of  such  objects  as  opposed  to  a  painting  program  which 
stores  only  bitmaps.  The  advantage  is  that  it  is  possible  to  change  any  element  of  the 
picture  at  any  time  since  each  part  is  stored  as  an  independent  object  whereas  once 
something  in  a  bitmap  has  been  overwritten  it  cannot  in  general  be  retrieved. 

WWW  (World  Wide  Web).  Frequently  used  (incorrectly)  when  referring  to  "The 
Internet",  WWW  has  two  major  meanings  -  First,  loosely  used:  the  whole  constellation  of 
resources  that  can  be  accessed  using  Gopher,  FTP,  HTTP,  telnet,  USENET,  WAIS  and 
some  other  tools.  Second,  the  universe  of  hypertext  servers  (HTTP  servers)  which  are  the 
servers  that  allow  text,  graphics,  sound  files,  etc.  to  be  mixed  together. 

XML  ('Extensible  Markup  Language).  A  new  standard  defining  an  "extremely  simple" 
dialect  of  SGML  suitable  for  use  on  the  World-Wide  Web. 

XPP  fXwision  Production  Publisher).  An  industrial  composition  and  pagination  system 
that  automates  the  production  of  complex  documents. 

of  contents.  Select  "View-Field  Codes"  to  display/hide  field  codes.  Chapter  number  is 
between  the  quotes  in  the  field  code. 
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Appendix  B.  Military  and  Industry  Technical  Manuals  Delivery  Specifications 


DOD 

INDUSTRY 

APPLICATIONS 

MIL-HDBK- 

59 

Provide  guidance  on  the  technology,  standards,  and 

procurement  process  as  related  to  the  translation  from  a 

paper  intensive  activity  to  one  operating  with  digital 

information 

MIL-STD- 

1840 

The  Primary  defense  standardization  document  for  the 

selected  CALS  standards,  identifies,  by  application,  which 

industry  standard  and  corresponding  DoD  standardization 

documentation  to  use  It  also  provides  standard 

“enveloping”  procedures  for  transferring  standard  data 

forms 

MIL-D-28000 

IGES 

Initial  Graphics  Exchange  Specifications  (IGES)-  A 

neutral  file  format  for  the  representation  and  transfer  of 

product  definition  data  among  CAD/CAM  systems  and 

application  programs 

MIL-M-28001 

SGML 

Standard  Generalization  Markup  Language  (SGML)- 

Markup  requirements,  tagging  and  generic  style 

specifications  for  page-oriented  documents  text 

MIL-R-28002 

CCITT 
GROUP 4 

The  efficient  compression  of  scanned  raster  images.  Uses 

the  code  from  the  Group  4  facsimile  recommendation  of 

the  International  Telegraph  and  Telephone  Consultative 

Committee  (CCITT).  A  “filed”  form  is  described  by  using 

the  architecture  nomenclature  of  International  Standard,  IS 

18613. 

Computer  Graphics  Metafile  (CGM)-  A  neutral  format  for 

the  description,  storage  and  communication  of  graphical 
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information 

EC/EDI  EC/EDI  Electronic  Commerce/Electronic  Data  Interchange 

(EC/EDI)-  The  electronic  interchange  of  business 
information  between  trading  partners.  Uses  standards 
formats  currently  defined  by  ANSI  X12  in  the  U.S., 
EDIFACT  in  the  Europe,  and  AECMA  2000  for  NATO 

STEP  STEP  Standard  for  the  Exchange  of  Product  Model  Data  (STEP)- 

A  computer  interpretable  data  representation  format  being 
developed  to  include  all  product  model  data  necessary  to 
define  geometry,  function  and  behavior  of  a  product 
throughout  its  life  cycle.  Product  Data  Exchange  using 
STEP  (PDES)  is  the  U.S.  standards  activity  supporting 
STEP 

MIL-STD-974  CITIS  Contractor  Integrated  Technical  Information  Service 

(CITIS)-  Contractor  provided-service  for  electronic  access 
and/or  delivery  of  contractually  committed  business  and 
technical  information  on  a  need  to  know  basis. 

MIL-M-87268  IETM  Prescribes  the  requirements  governing  the  creation  of 

Interactive  Electronic  Technical  Manual  (IETM) 
presentation  software  applicable  to  a  computer  -controlled 
Electronic  Display  System  (EDS). 

MIL-D-87269  IETM  Prescribes  the  interchange  format  for  delivery  of  an  IETM 

database  to  the  Government 

MIL-Q-87270  IETM  Prescribes  the  requirements  for  an  IETM  Contractor’s 

Quality  Assurance  (QA)  program 


MIL-HDBK- 

SGML 

Provides  guidance  in  the  application  of  MIL-M-28001, 

SGML  (draft) 

which  is  based  on  ISO  8879,  Standard  Generalized 

Markup  Language.  Data  prepared  in  accordance  with  these 

"D 

guidelines  will  facilitate  the  automated  storage,  retrieval, 

interchange,  and  processing  of  technical  documents  from 

varied  data  sources 

(Villeca,  1997:9) 
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Appendix  C.  Classes  of  lETMs 


CLASS 

DISPLAY 

DATA  FORMAT 

FUNCTIONALITY 

0 

Full  page  viewing 

Film 

Printed  pages 

Printed  pages 

Word  processor 

View  pages  (No  intelligent 
indexing) 

Microfilm  images 

SGML  or  Page  description 
language 

1 

Full  page  viewing 

Bitmap  (raster) 

Access  pages  by  intelligent 
index/header  info 

Page-tumer/Next  function 

Indexing  and  header  files 
(Navy  Mil  29532) 

View  page  with  pan,  zoom, 

Intelligent  index  for  user 

etc.,  tools 

access 

MIL-R-28001  or  Postscript 

to  page  images 

pages 

Limited  use  of  hot-spots 

Page  integrity  preserved 

Generic  COTS  imaging 

Useful  for  library  or 

system  formats 

reference  use 

2 

Primary  view  is  scrolling 

Text  -  ASCII 

Browse  through  scrolling 

text  window 

Graphics  -whatever  viewer 

info 

Hot-spot  access  (Hyper¬ 

support  -e.g.,  BMP  or 

User  selection  of  graphics  or 

links)  to  other  text  or 

CALS 

hot-spot  reference  to  more 

graphics 

Can  be  SGML  tagged  -  no 

text 

User  selection  and 

page  breaks  (browser) 

Hot-spot  and  cross- 

navigation  aids  (key-word 

reference  usually  added 

search,  on-line  indices 

Access/index  often  COTS 
dependent  with  Hypertext 

after  original  authoring 

Minimal  text-formatting 
for  display 

browser 

Generic:  COTS  with 

User  selectable  call  to 
(launch)  another  process 

Hypertext  browser 

3 

View  smaller  logical  block 

Linear  ASCII  with  SGML 

Dialog-driven  interaction 
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of  text  -  less  use  of 
scrolling 

Interaction  through  dialog 
boxes 

Interaction  per  MIL-M- 
87268  to  extent  possible 


tags 

SGML  with  content  vice 
format  tags 

Maximum  use  of  MIL-D- 
87269 

Generic:  SGML  tags 
equivalent  to  MIL-D- 


Logical  display  of  data  in 
accordance  with  content 

Logical  NEXT  and  BACK 
functions 

User-selectable  cross-refs 
and  indices 


4 


Text  and  graphic 
simultaneously  displayed 
in  separate  window  when 
keyed  together 


View  smaller  logical  block 
of  text  -  very  limited  use  of 
scrolling 

Interaction  through  dialog 
boxes  with  user  prompts 

Interaction  per  MIL-M- 
87268 

Text  and  graphic 
simultaneously  displayed 
in  separate  window  when 
keyed  together 


87269 


Fully  attributed  DB 
elements  (MIL-D-87269) 

MIL-D-87269  content  tags 
with  full  conformance  with 
Generic  Level  Object 
Outlines  (architectural 
forms) 

Authored  directly  to 
database  for  interactive 
electronic  output 

Data  managed  by  a  DBMS 

Interactive  features 
"authored  in"  vice  added- 
on 


Content  specific  help 
available 


Dialog-driven  interaction 

Logical  display  of  data  in 
accordance  with  content 

Logical  NEXT  and  BACK 
functions 

Useful  as  interactive 
maintenance  aid 

User-selectable  cross-refs 
and  indices 

Content  specific  help 
available 


Generic:  COTS  equal  to 
MIL-D-87269  data 


definition  and  tags 


5 


Same  as  Class  4  for  IETM 
function 

Interactive  electronic 
display  per  MIL-M-87268 

Expert  system  allows  same 
display  session  and  view 


IETM  info  integrated  at  the 
data  level  with  other 
application  info 

Does  not  use  separate 
databases  for  other 
application  data. 


Single  viewing  system  for 
simultaneous  access  to 
multiple  info  sources 

Same  as  Class  4  for  IETM 
functions 

Expert  system  to  assist  in 
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system  to  provide 

Identical  to  Class  4 

NEXT  functions,  based  on 

simultaneous  access  to 
many  differing  functions 
(e.g.,  supply,  training, 
troubleshooting) 

standards  for  IETM 
applications  data  per  MIL- 
D-87269 

Coding  for  Expert  Systems 
and  AI  modules  when  used 

Generic:  COTS  equal  to 
MIL-D-87269  data 
definition  and  tags 

info  gathered  in  session 

(Jorgensen,  1994:8) 
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Appendix  D.  Summary  of  Research  Questions  Given  to  O’Nell  & 

Associates 


General  Questions  about  IETM  development  process  in  O’Neil  &  Associates,  Inc. 

1 .  Description  of  O’neil  &  Associates,  Inc. 

2.  In  which  cases  are  IETMs  preferred? 

3.  Steps  of  an  IETM  development  process. 

4.  Identification  of  each  step. 

•  How  long  does  it  take  to  complete  each  step? 

•  How  many  people  work  on  it,  inside/outside  and  why? 

•  How  does  each  worker  contribute  to  the  project,  how  much  time  do  they  spend? 

•  What  are  the  inputs  and  outputs  for  the  step? 

•  How  is  the  decision  made  among  alternatives  (type  of  software,  hardware, 
methods,  etc.)?  For  example  which  one  is  preferred,  scanning  and  using  OCR  or 
rewriting  in  a  different  way? 

•  What  are  the  components  of  each  step? 

5.  Schedule  and  resource  allocation  for  the  projects. 

6.  What  is  the  schedule  plan,  does  each  step  have  to  follow  each  other,  or  can  they  be 
done  simultaneously? 

7.  How  much  time  and  resource  allocated  for  each  step?  What  are  the  resources? 

8.  Cost  issues  of  projects. 
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Which  cost  allocation  method  is  used?  How  correct  do  you  think  is  this  method? 
Difficulties  in  allocating  cost  in  that  kind  of  a  project. 

Total  cost  of  projects,  cost  of  each  step,  cost  among  alternatives. 


9.  Life  cycle  issues  (maintenance  and  support). 

Questions  about  Intercept  Project 

1 .  Description  of  the  customer. 

2.  Description  of  the  project. 

3 .  Implementation  of  IETM  development  steps  in  that  case. 

4.  Total  cost,  cost  of  each  step,  and  cost  allocation  methods. 

5.  Problems  encountered  in  the  project,  and  how  were  they  handled. 

6.  Interviews  with  the  personnel  who  worked  on  the  project. 

7.  Schedule  and  resource  allocation  for  the  project. 

8.  Changes  from  general  implementation  methods  and  their  reasons. 

9.  Interactions  between  the  customer  and  the  firm. 
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